re: a cross-reference kept recommending a route the cited page had killed

`menu-navigation-semantics.md` advertised "the cheap way to finish this":
read 0x828A690C as a live screen id and 0x828F38AC as the cursor, under
--gpu=null with no screenshots. `menu-state-in-memory.md` withdrew exactly that
identity ON THE SAME DAY it was published -- three back presses send the
"cursor" 36 -> 38 -> 40 -> 41, and a cursor returns when you go back. They are
monotonic counters; the cross-run agreement is the same key sequence producing
the same count.

The recommendation stood for three days after the page it cited had killed it,
and either document would have been believed on its own. Marked withdrawn where
it was recommended, with what the words ARE still good for (did the game react?)
and the consequence: a measured button->GamePart-id binding stays unfinished
because no screen enum has been located.

Also delivers Q4 to HANDOFF in the shape the port asked for -- exactly one
main-menu button opens a GP_TITLE entry (EXTRAS -> entry 6/9); the other four
leave the archive. That was measured on 2026-08-28 and was reachable only from
docs/re/, which the protocol counts as undelivered.

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

docs/re/menu-navigation-semantics.md

@@ -66,15 +66,33 @@ black-screen hang that ends the run
 ([`ui-paint-order-third-permutation.md`](ui-paint-order-third-permutation.md)),
 and this iteration needed the session. It is the one destination still unmeasured.
 
-### The cheap way to finish this, and to make it a measurement
+### 🔴 The "cheap way to finish this" was a dead route — WITHDRAWN 2026-08-29
 
-`0x828A690C` holds a **live screen id** — `1` title, `3` main menu, `4` extras —
-and `0x828F38AC` the cursor ([`menu-state-in-memory.md`](menu-state-in-memory.md)).
-Reading those while pressing Ⓐ turns "the screen said OPTIONS" into a measured
-transition, and works under `--gpu=null` with no screenshots at all. ⚠️ Note that
-those values are **not** GamePart ids — `GP_TITLE` is GamePart 0 and `GP_EXTRAS`
-is 5, but the word reads 1 and 4 — so it is a third enumeration and mapping it to
-the id table is itself unfinished work.
+This section used to say: *`0x828A690C` holds a live screen id (1 title, 3 main
+menu, 4 extras) and `0x828F38AC` the cursor; read them while pressing Ⓐ and the
+transition becomes a measurement, under `--gpu=null` with no screenshots.*
+
+**Do not do that. Those words are monotonic counters, not state.**
+[`menu-state-in-memory.md`](menu-state-in-memory.md) withdrew that identity **on
+the same day it was published** — driving deep and then pressing Ⓑ three times
+sends the "cursor" `36 → 38 → 40 → 41`, and a cursor returns when you go back.
+The values match across runs because the same key sequence produces the same
+count, not because `3` *means* main menu. With the sign-in fix the sequence runs
+`3 → 5`, skipping `4` entirely, so "4 = extras" was never a screen at all.
+
+This page kept recommending the route for three days after the page it cited had
+killed it. ⚠️ **A cross-reference is not a citation unless you re-read the target**
+— the two documents disagreed in the corpus and either would have been believed
+on its own.
+
+✅ **What those words are still good for**: all three advance if and only if the
+game responds to input, and are stable when it does not. Read them as *"did the
+game react?"*, never as *"which screen is this?"*. Screen identity still has to
+come off the framebuffer.
+
+❔ **So a measured button→GamePart-id binding remains unfinished**, and for the
+reason it always was: no screen/state enum has been located in guest memory. The
+ids in the table below stay a name match.
 
 ## ✅ `NEW GAME` — measured 2026-08-28, and it is not a hang