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`