docs: decision 145 (row 122 migration is print-only; Jason installs the output in Mos's window)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/plans/2026-09-26_lead-decisions.md

@@ -3282,3 +3282,22 @@ which stay with him. Each item names who decided it and what happened.
       entry through Mos, and the live check runs after he adds it.
     - Nothing goes to Jason for this. My 2026-10-14 PM standup listed it
       under Needs Jason; Mos's reply corrects that.
+
+145. **Row 122's migration is print-only (2026-10-15, Rocko's request
+    after #1616 comment 28516).** The new validator refuses `launch.max`,
+    so a new host can't start on an unmigrated file, and the old host has
+    no limits verb. Rocko offered a local `--write` helper that applies
+    the human proof outside the broker. I chose print-only instead.
+    - `mosaic limits migrate` needs no running bus. It reads the file it
+      is given and prints the converted whole document, and that is all
+      it does. There is no `--write`.
+    - Jason runs it and installs the output himself in the window Mos
+      runs, with the PM run idle, and the re-pin follows in the same
+      window (decision 144). The packet carries the exact command, and
+      no agent runs it on the live file.
+    - `mosaic limits` and the Settings form are the only writers, and
+      both write through the broker behind the existing human proof.
+    - Why: a local helper would be a second write path to the business
+      file and a second copy of the human proof, which is bound to the
+      bus's own `human-cli.mjs` path (#225). A one-time migration doesn't
+      justify a new security boundary.