re: the title menu wraps -- Q5 measured, Q4 driven, and one of my own

method lines withdrawn

Q5, measured off two boots: up/down move one item and WRAP at both ends
on the 5-item main menu and the 3-item EXTRAS alike; left/right do
nothing; B goes up one level and restores focus to the item you came
from (4/4); B on the main menu returns to the title; B on the title does
nothing. The menu opens on TUTORIAL -- the middle item -- 2/2, though a
third recorded run implies NEW GAME, so that one is reproducible rather
than invariant and says so.

Q4 by driving: LOAD GAME opens the save-slot list, TUTORIAL the lesson
list, OPTIONS the settings menu, EXTRAS build 6, MISSION SELECT the stage
list. NEW GAME is not tested -- A on it hangs the emulator and this
iteration needed the session. The GamePart ID behind each is NOT
measured: it is the entry of the decoded id table whose name matches the
screen I saw, and the page says so rather than wearing the badge.

And the withdrawal. Last iteration I wrote that these menus drop d-pad
presses shorter than ~0.3s. They do not. Once wrap is measured, every
press count I had is exactly right -- four presses moved four steps
THROUGH the bottom, which lands one above where a non-wrapping menu
would. I invented hardware flakiness instead of testing the ends of the
list. METHOD keeps the withdrawal rather than deleting the line.

Also: label brightness is not a cursor oracle here -- the background art
outshines the highlight on some rows. menu_focus.py reads the focus ring
instead, 254 vs <82, no tuning.

docs/re/METHOD.md

@@ -117,16 +117,26 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
 * **Measure animation in submitted frames, not in seconds.** `VdSwap` counts are
   the guest's own frames, so an emulator at 80 % of real time does not move them;
   a stopwatch reading does, silently and by an unknown factor.
-* **This game's menus drop d-pad presses shorter than ~0.3 s.** `pad.py dpad`
-  defaults to 0.06 s, and its docstring says longer "auto-repeats and
-  overshoots". On the title main menu that default is *dropped*: four presses at
-  0.12 s moved the cursor one step, four at 0.20 s moved it none, while
-  0.30/0.50/0.80 s each moved it exactly one step and none of them repeated. A
-  scripted navigation that comes out one item short is this, not a wrong item
-  count — screenshot after every step and check the cursor rather than trusting
-  the press count.
+* **~~This game's menus drop d-pad presses shorter than ~0.3 s.~~ WITHDRAWN
+  2026-08-28 — the menu WRAPS, and I had not measured that.** The claim came from
+  reading a cursor that ended up "one item short"; once wrap-around at both ends
+  was measured ([`menu-navigation-semantics.md`](menu-navigation-semantics.md)),
+  every one of those press counts is exactly right — four presses at 0.12 s moved
+  four steps *through the bottom*, which lands one above where a non-wrapping
+  menu would put it. **No press was ever dropped.** The real lesson is the
+  general one: *a step count is only readable once you know the topology*, and I
+  invented a hardware-flakiness story rather than testing the ends of the list.
+  Still true and worth keeping: screenshot after every step and read the cursor,
+  rather than trusting arithmetic over the press count.
 * **A screenshot taken right after a transition can catch a screen mid-fade.**
   A grab 2.5 s after Ⓑ returned the game to the title showed the title art with
   no `PRESS Ⓐ BUTTON` plate; one second later the plate was there. That very
   nearly went into the corpus as "the returned title has no plate". Sample a
   changing screen several times before writing down what it does *not* contain.
+* **Do not identify a menu cursor by label brightness.** The obvious oracle —
+  "the focused label is the brightest row" — fails on this game's menus, because
+  the background art is brighter behind some rows than the highlight is. It
+  confidently named the wrong item on a frame whose ring was plainly elsewhere.
+  Detect the **focus ring** in the gutter left of the labels instead
+  (`tools/re-capture/menu_focus.py`, 254 vs <82 — no threshold tuning needed),
+  and look at the PNG before believing either.