re: (A) on a settled boot title DOES reach the menu -- the withdrawal explained

Clearing my own debt: I withdrew navigation.md's "boot title accepts a single A"
counter-example as confounded by three concurrent emulators and never re-ran it,
which left the claim unsupported rather than settled.

Clean trial: exactly one emulator verified by count, gated on the plate pulse
(glyph in [500,2500] held 12 samples) so the press lands on the BOOT title rather
than the attract loop's, delivery confirmed at [file-pad] keystroke vk=5800
down/up. Glyph after the press is 0 at +2 s and +4 s -- the transition -- then 327
steady from +6 s through +39 s.

327 is a proxy and reading a proxy is the habit this corpus keeps cataloguing, so
the screen was checked with which_title_screen.py instead: main_menu at RMSE
19.91 and 20.08 with margin ~10, inside the 9.9-11.7 band its control establishes
on four known captures. The before frame gives the "neither" signature at margin
0.10, correctly, since the title is neither main_menu nor extras.

So the count is 3 of 3, the latency is 4-6 s -- which is why a script that
presses and looks 0.5 s later concludes the press was dropped -- and the two
earlier failures were the confound, not the game.

Refutation attempted: sylpheed-port's leaf segment rates. Derived independently
from the disc and they SURVIVE exactly -- pteff03 +4.0000 then +4.0000 then a
hold, pteff03a -4.0667 then -4.0625 then a hold. So their inversion stands: my
linearity gate fails on the leaf whose declared track is perfectly straight.

And records the third structural consequence of main being stale, which they
raised: HANDOFF.md is the delivery contract and it lives on an unmerged branch,
so their checkout contains none of this week's entries. Findings written into the
contract reach them only through messages -- the channel the protocol says does
not count as delivery. Writing it in the contract is necessary and not sufficient
when the contract lives where the other party cannot see it.

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

docs/game/navigation.md

@@ -321,7 +321,22 @@ Traps that read as bugs but are not, all measured ✅:
   if you must use `-9`, `rm -f /tmp/xenia-canary.lock` after. **And assert the
   emulator is alive before entering any wait loop** — `ps -C xenia_canary` — so
   the loop cannot spend its whole deadline on nothing.
-* 🔴🔴 **THE ENTRY BELOW IS WITHDRAWN — the experiment was confounded.** When it
+* ✅ **Ⓐ on a settled boot title DOES reach the main menu — re-run clean,
+  2026-08-30, and the withdrawn counter-example below is now explained.** One
+  trial, **exactly one emulator verified by count**, gated on the plate pulse
+  (glyph in [500, 2500] held 12 samples) so the press lands on the boot title
+  rather than the attract loop's. Delivery confirmed (`[file-pad] keystroke
+  vk=5800 down`/`up`). Glyph after the press: `0, 0` at +2 s and +4 s — the
+  transition — then **327 steady from +6 s to +39 s**. ⚠️ 327 is a proxy, so the
+  screen was checked with [`which_title_screen.py`](../../tools/re-capture/which_title_screen.py)
+  instead: **`main_menu` at RMSE 19.91 and 20.08, margin ~10**, inside the 9.9–11.7
+  band its control establishes on four known captures. The `before` frame gives
+  the "neither" signature (margin 0.10), correctly, since the title is neither.
+  📌 **Latency 4–6 s**, which is why a script that presses and looks 0.5 s later
+  concludes the press was dropped. So the count is now **3 of 3**, and the two
+  earlier failures were the three-emulator confound, not the game.
+
+* ~~🔴🔴 **THE ENTRY BELOW IS WITHDRAWN — the experiment was confounded.**~~ When it
   ran, **three emulators were live at once** (started 15:39, 15:44 and 16:12 on
   2026-08-30), all reading the same `/tmp/xenia_pad.txt` and sharing display `:98`.
   A press written to that file is delivered to **every** instance, and `screenshot`

docs/re/main-is-the-stale-era.md

@@ -128,6 +128,30 @@ build warns them. The port is insulated only because their exporter pins
 the cost of not doing it: the fix is measured-correct against the oracle, and it is
 reachable only from a topic branch.
 
+## 🔴 Third structural consequence: HANDOFF itself is not delivered
+
+`sylpheed-port` raised this and it is the sharpest one yet. **`docs/port/HANDOFF.md`
+is the contract — "an answer not reachable from there is not delivered" — and it
+lives on an unmerged branch.** Their checkout is `origin/main`, 145 commits behind;
+the HANDOFF they read contains none of this week's entries. So findings written
+into the contract reach them **only through messages**, which is precisely the
+channel the protocol says does not count as delivery.
+
+Nothing either agent did is wrong. **Writing it in the contract is necessary and
+not sufficient when the contract lives on a branch the other party cannot see.**
+They have mirrored the load-bearing statuses into their own `BLOCKED.md` and
+`DECISIONS.md`, sourced to a sha, so their tree does not depend on a HANDOFF they
+cannot read — which is the right local fix and not a substitute for the merge.
+
+Three consequences now, all recorded rather than worked around:
+
+1. every published ref except this branch **builds the decoder the game disagrees
+   with** (the measured cost is above);
+2. the port's `Cargo.toml` pin is **load-bearing, not vestigial** — they had been
+   checking each iteration whether they could drop it, which would have silently
+   downgraded their exporter;
+3. **the delivery contract does not reach the party it exists to serve.**
+
 ## What this does not settle
 
 * **Why the `title_jp` measurement disagrees with the port's.** Recorded above with