docs/re: a second screen captured, and the two title states pinned down

Two results, one of which closes the navigation problem the last three
iterations kept hitting.

**The title states.** The hypothesis was that the attract-loop title is a
non-interactive presentation that omits the PRESS (A) plate. Half right:

* the state distinction is REAL — a single (A) on the title that ends the boot
  opens the main menu, 2 of 2 in independent runs, one of which never pressed
  F10; the title the attract loop returns to accepts nothing, not (A), START, B,
  BACK, X or Y, across dozens of delivered presses;
* the proposed tell is REFUTED — capturing the draws in both states in one run
  gives 13 quads at identical rects, ptbtn00 and ptbtn00f included. The two are
  identical to the renderer and different only to the guest.

So there is now a reliable route to the menu: first title after boot, one tap.

**The main menu's paint order**, captured with it. Its sprites are GP_TITLE
build 5's, and ptframe1/ptframe2/ptbtn01f land within 4 px of their declared
resting placements — an independent placement check on an untouched bundle.

It does NOT settle the ordering question, and the entry says so: build 5 lists
its background at indices 1-2, so declaration order and "background first"
predict the same sequence here. Same failure mode as GP_READY_ROOM/GP_OPTIONS.
What it does establish is that the title's disagreement is not a decode
artefact — same pak, same engine, one build that follows its table and one that
does not.

docs/re/canary-scripted-input-traps.md

@@ -132,19 +132,29 @@ useless, it **breaks the run** — 88 presses left a black screen that never cam
 back (no crash, no throw, the emulator healthy). The script no longer taps
 during boot; the intro takes ~3.5 minutes and gets to the title by itself.
 
-**So the difference is not the number of presses or the button.** The one
-success came on a title that appeared ~83 s into a warm boot; the failures came
-on titles that appeared after 292 s and a full attract cycle. The obvious
-reading — that the attract-loop title is a non-interactive presentation and the
-post-boot title is the interactive one — is a **hypothesis, unconfirmed**, and it
-is what to test next.
+**So the difference is not the number of presses or the button — it is which
+title you are looking at**, and that is now measured rather than guessed:
+
+* the title that **ends the boot sequence** accepts a single Ⓐ and opens the main
+  menu — **2 of 2**, in independent runs, one of which never pressed F10;
+* the title the **attract loop returns to** accepts nothing — Ⓐ, START, B, BACK,
+  X, Y, dozens of presses, every one delivered, none swallowed.
+
+**The recipe, then:** launch, wait for the first `title` classification, tap Ⓐ
+once. Do not tap during the boot, and do not wait for a second title.
+
+The tell is *not* visible in what the game draws — a `log_ui_draws` capture in
+each state gives 13 quads at identical rects, `ptbtn00` (the `PRESS Ⓐ BUTTON`
+plate) included in both. See
+[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md).
 
 ## Still open
 
-Which title state accepts input, and how to tell them apart from outside. A
-`log_ui_draws` capture in each state would say whether the two composite
-differently (the interactive one draws `ptbtn00`, the `PRESS Ⓐ BUTTON` plate,
-from build 2 — if the attract title omits or replaces it, that is the tell and it
-is visible in one capture). Until that is pinned down, reaching the main menu is
-a matter of luck, which is not a basis for the second screen's paint-order
-capture.
+**Why** the attract title stops accepting input, given that it draws exactly the
+same thing. Nothing in the composition, the input path or the sign-in state
+differs; the difference is in the guest's own state machine, and reading it means
+reading that code.
+
+Not open any more, and worth stating because it was the thing blocking the RE:
+reaching the main menu is now routine (first title, one Ⓐ), and the second
+screen's paint order has been captured with it.