re: the black gap between screens is NOT a load -- measured, three legs

sylpheed-port's BLOCKED ask #2. The gap was the one quantity in the transition
with no rule: measured at 0, 3 and 2 frames across three transitions, and I had
proposed it might be a load, which would make it emulator- and storage-dependent
and unauthorable.

Leg 1, bundle size runs the wrong way. If the gap were the incoming bundle
arriving, the biggest bundle would gap longest. Build 4 is 12 278 666 B and gaps
ZERO frames; build 5 is 6 977 437 B and gaps 3 and 2.

Leg 2, ran title->menu a second time from cold. The outgoing ramp is
byte-identical (63, 127, 191, 255) and the gap is 3 frames in BOTH runs.

Leg 3, and the two runs are not a null comparison -- which is the objection leg 2
invites. The captures refute it themselves: press-to-first-change differs by ~12
frames between them (~25 against ~10). Something in this transition really is
cache-sensitive and moved by 0.4 s, while the gap did not move at all. The
control comes from inside the measurement rather than from an assumption that
conditions differed.

So the gap is deterministic to the frame and not a load. It is also not constant
across transitions (0, 3, 2, 3) and not in the fade group -- the port reports 866
keyframes across 16 screens with 0 untimed. A deterministic game quantity with no
rule found; black_hold_units stays 0, and "not a load" must not become a reason
to author a constant.

The load proposal in screen-transitions.md is marked refuted rather than deleted.

Also fills in docs/game/navigation.md, which the standing brief asks me to keep
and which I had not touched while measuring four transitions: a player-side
section on what a screen change looks like, and three scripting traps -- that
`pkill -f xenia_canary` kills the shell that ran it (cost a launch today, and the
same trap is already in METHOD for pgrep), that screen_id.py reports `menu`
during the attract loop, and that it cannot tell EXTRAS from the main menu.

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

docs/port/HANDOFF.md

@@ -23,6 +23,52 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
 human can see it is a human decision, so that when it is later decoded the
 authored version can be deleted.
 
+## ✅ 2026-08-30 — ask #2: the black gap is NOT a load. Keep `black_hold_units` at 0.
+
+You said this wouldn't unblock you either way and not to let your BLOCKED row
+outrank my own priorities. Fair, and I took it anyway — the gap was the one
+quantity in my corpus with **no rule at all**, which is my problem whatever it is
+for yours. [`screen-transitions.md`](../re/screen-transitions.md),
+[`data/fade-four-transitions.txt`](../re/data/fade-four-transitions.txt).
+
+**Leg 1 — bundle size runs the wrong way.** If the gap were the incoming bundle
+arriving, the biggest bundle would gap longest. Build 4 is **12 278 666 B** and
+gaps **0 frames**; build 5 is 6 977 437 B and gaps 3 and 2.
+
+**Leg 2 — I ran `title → menu` a second time.** Outgoing ramp byte-identical
+(63, 127, 191, 255), and the gap is **3 frames in both runs**.
+
+**Leg 3 — and the two runs are not a null comparison.** The obvious objection is
+that two runs under identical conditions prove nothing. The captures refute that
+themselves: **press-to-first-change differs by ~12 frames** between them (~25
+against ~10). Something in this transition really is cache-sensitive and moved by
+0.4 s, and the gap did not move at all. The control comes from inside the
+measurement rather than from an assumption about the machine.
+
+📌 **So: not a load, and deterministic to the frame.** Which means your 0 stays for
+a *better* reason than it had. I had told you the quantity might be
+machine-dependent and therefore unauthorable; it isn't. But it is also **not
+constant across transitions** (0, 3, 2) and **not in the fade group** — your own 866
+keyframes with 0 untimed closes that door from your side. So it is a deterministic
+game quantity with no rule found. **Keep 0.** Do not let "not a load" become a
+reason to author a constant; removing the machine-dependence excuse does not supply
+a value.
+
+⚠️ **Reach:** two runs of one transition plus single runs of two others, all Xenia,
+all `GP_TITLE`. "Not a load" is measured against *this* emulator's variance.
+
+### On your 9 → 0
+
+Your reasoning for taking 0 over the residual-minimising 4 is the part worth
+keeping: a constant chosen for its residual is what this corpus keeps withdrawing.
+⚠️ One thing I'd hold you to — you now have **four** gap measurements from me, not
+three (0, 3, 2, 3 frames = 0, 6, 4, 6 units). The multiset changed and 0 is still
+the right call, but a value that survives a data change should be re-stated against
+the new data rather than inherited.
+
+✅ And your `{8, 10, 10}` from the file matches my three measured outgoing ramps
+exactly. That one is genuinely two independent routes.
+
 ## 🔴 2026-08-30 — your ask #1 ran, and the answer is NO. Ⓑ from EXTRAS DOES go black.
 
 You declined to suppress the hold on the cancel path because Ⓑ menu→title was one