port: the refuted 24-unit constant was living in a default; make it loud instead

ScreenView.exit_ramp_units defaulted to 24.0 -- the constant HANDOFF ask 2 told
this port to author and that it refused, since the file's own ramp is 10 units.
The authored entry was deleted as progress when the corrected record layout
removed the unknown, and the default plus boot.gd's timing.get(..., 24.0) made
that deletion a no-op.

Both use sites are unreachable on today's export (866 keyframes, 0 untimed), so
the branch is kept for an older export but no longer invents: the default is -1.0
meaning not supplied, and an untimed group now raises an error naming the screen
rather than fabricating a duration.

My first verification accused the change: main_menu 641941 px and extras 226009 px
changed, on a branch that cannot execute and with no error raised. The cause was
--screen=X --capture= firing at an uncontrolled instant -- t=9.00 in the earlier
run against t=8.00 in the later one, one unit apart mid-build-in. Three runs now
are byte-identical, so it is not noise; the instant is stable within a session and
moves between them. Re-run with --time=1.0 pinned, old against new is
byte-identical on all four screens.

Records the harness limitation: --screen=X --capture= cannot be used for
before/after comparison on an unsettled screen, which also explains the earlier
settle-vs-rest confound.

Also corrects my overstatement that other tools call the CLI -- verify-screen is
the only one, checked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-169 sections. Search this before re-deriving anything.
+170 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -180,6 +180,7 @@ dies, which is what this file is for.
 * [Re-deriving `black_hold_units` against four measurements, not three](#re-deriving-black_hold_units-against-four-measurements-not-three)
 * [🔴 CORRECTION: my "the eras render identically" measurement was void](#correction-my-the-eras-render-identically-measurement-was-void)
 * [🔴 CORRECTION: my branch *is* the stale era, and the reference binary was never the workspace build](#correction-my-branch-is-the-stale-era-and-the-reference-binary-was-never-the-workspace-build)
+* [`exit_ramp_units`: the refuted constant was living in a default](#exit_ramp_units-the-refuted-constant-was-living-in-a-default)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -9707,3 +9708,54 @@ plateau **flat to 1.2 RMSE across 105 units**, so the 16.7 era margin is ~14× t
 flatness and decisive, while **settle-vs-rest at 1.5 is inside it**. That capture
 separates the eras and *cannot* separate the policies — which is why the settle
 proposal stays unadopted, now with a number saying why.
+
+## `exit_ramp_units`: the refuted constant was living in a default
+
+`ScreenView.exit_ramp_units` defaulted to **24.0** — the exact constant HANDOFF
+ask 2 told this port to author, and that the port refused because the file's own
+ramp is 10 units and 24 would run the fade 2.4× too long. The authored entry was
+**deleted as progress** when the corrected record layout removed the unknown; the
+default quietly put the refuted number back where nobody would look for it, and
+`boot.gd`'s `timing.get("exit_ramp_units", 24.0)` made the deletion a no-op.
+
+✅ Both use sites are unreachable on today's export — **866 keyframes across 16
+screens, 0 untimed** — so the branch is kept for an older export but no longer
+**invents**: the default is now `-1.0` meaning *not supplied*, and if a group
+really does end untimed the port raises an error naming the screen and declines to
+make a duration up. Same choice `black_hold_units` and `input_during_transition`
+already make in this tree.
+
+### 🔴 My first verification was confounded, and it accused the change
+
+Before/after renders of four screens: `title` and `press_start` byte-identical,
+**`main_menu` 641 941 px changed and `extras` 226 009** — 70 % of the frame, on a
+change that raised no error and whose branch cannot execute.
+
+The cause was not the edit. **`--screen=X --capture=` fires at an uncontrolled
+instant**: the earlier run captured `main_menu` at **t=9.00**, the later one at
+**t=8.00**. One keyframe unit apart, mid-build-in, is most of the picture. Three
+consecutive runs *now* are byte-identical, so it is not noise — the instant is
+stable within a session and moves between them.
+
+✅ Re-run with the instant pinned (`--time=1.0`), old code against new:
+**byte-identical on all four screens.** The change is a no-op, as the keyframe
+census said it must be.
+
+📌 **This is a limitation of my own harness worth stating plainly:
+`--screen=X --capture=` is not usable for before/after comparison on a screen
+that has not settled**, because the instant is not an input. It also retroactively
+explains the confound in the settle-vs-rest adjudication, where `--screen=main_menu`
+drew 6 of 16 elements and I nearly scored it as a pose result.
+
+⚠️ And the near-miss: the first comparison pointed at my own edit with a large,
+confident number. Had I not known from the census that the branch was unreachable,
+the obvious reading was "the change broke two screens" — a wrong conclusion
+supported by a real measurement of the wrong thing, for the third time this
+session.
+
+### Correcting my own overstatement
+
+Last iteration I said the era guard "closes that for `verify-screen` only, not for
+the other tools that call the CLI". ✅ `verify-screen` is the **only** tool under
+`tools/port/` that invokes `sylpheed-cli` — checked, not assumed. The guard covers
+every caller there is.