tools: a working route to the menu, and the classifier that could not see it

screen_id.py called the main menu "other". Its menu rule required a near-white
fraction above 1.5%, measured in 2026-07; the menu reached from the boot title
measures 0.03% (mean 13,26,59 — dark, strongly blue, essentially green-free).
That is worse than a cosmetic miss: a script that waits for "menu" and never
sees it reports the navigation as failed while the menu is on screen, which is
exactly what happened here. Both measured signatures are now documented in the
code and both classify.

menu_draw_capture.sh now taps ONCE on the first title rather than up to 40 times:
repeating was measured to be useless (the attract title accepts nothing) and the
first title accepts a single press.

title_states_capture.sh is new — it captures the draw list in both title states
in one run, which is what refuted the "the attract title omits the button plate"
theory.

docs/re/BACKLOG.md

@@ -171,14 +171,18 @@ available in the container.
 **And a second screen is NO LONGER BLOCKED, but it is not routine either.** The
 main menu has been reached (screenshot in
 [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)), so the
-"Ⓐ is dead" reading is withdrawn. But the scripted reproduction **failed**: 40
-presses at 1/s move nothing, and neither do START/B/BACK/X/Y, with every press
-verifiably delivered and nothing swallowed. The single success came on a title
-that appeared ~83 s into a warm boot; the failures on titles that appeared after
-a full attract cycle. The reading that the attract-loop title is a
-non-interactive presentation is a **hypothesis**, and the cheap test is a
-`log_ui_draws` capture in each state — if the interactive one draws `ptbtn00`
-and the attract one does not, that is the tell.
+"Ⓐ is dead" reading is withdrawn. **Now routine**: the title that ends the boot sequence accepts a single Ⓐ (2 of
+2 runs); the title the attract loop returns to accepts nothing (Ⓐ, START, B,
+BACK, X, Y — dozens of delivered presses). The proposed tell was refuted on the
+way: the two states draw **13 identical quads**, `ptbtn00` included, so they
+differ only to the guest. Recipe: first title after boot, one tap, and never tap
+during the boot (88 presses over the intro ends on a permanent black screen).
+
+**The second screen is captured** — the main menu, `GP_TITLE` build 5 — and it
+does not discriminate: its background sits at declaration indices 1–2, so
+"declaration order" and "background first" predict the same sequence. Same
+failure mode as `GP_READY_ROOM`/`GP_OPTIONS`. The next screen worth capturing is
+one whose background sits **late** in its table, as the title's does.
 
 The earlier reading, kept because it is what the evidence looked like: the
 title's Ⓐ leads into a content/save path that crashes the guest with