docs/re: the scripted route to the menu does not work — measured, not assumed

The previous entry named the next step: "tap (A) once per second and see whether
the success rate goes to 1". It was run. The answer is no.

40 presses at 1/s on the title change nothing, and neither does one each of
START, B, BACK, X and Y. Every press was delivered (the driver logs down/up for
each) and the new [RE-INPUT] diagnostic never fired, so nothing was swallowed —
the guest received them and ignored them.

Also recorded, because it destroys a run rather than merely wasting it: tapping
(A) through the boot (88 presses over the intro) ends on a permanent black
screen with no crash and no throw.

What is left is a difference in STATE, not in input: the one 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 attract-loop title is a non-interactive
presentation" is written down as a hypothesis with the experiment that would
settle it — a log_ui_draws capture in each state, looking for ptbtn00.

docs/re/BACKLOG.md

@@ -171,10 +171,14 @@ 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; what remains is that Ⓐ advances the title only
-intermittently — one success in about four tries, with the press verifiably
-delivered each time. A reliable route to the menu is the next cheap step, and it
-is what the second screen's capture needs.
+"Ⓐ 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.
 
 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

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

@@ -109,10 +109,42 @@ and the window has not been pinned down.
   looked like hard evidence for the `IsUIActive` theory and means nothing. The
   theory had to be tested with a real log line instead.
 
+## The scripted reproduction was tried, and it failed
+
+"Tap Ⓐ once per second and see whether the success rate goes to 1" was the next
+step this entry named. It was run (`tools/re-capture/menu_draw_capture.sh`), and
+the answer is **no**:
+
+| run | what was pressed | result |
+|---|---|---|
+| E | **one** Ⓐ on the first title after boot | **main menu** |
+| F | **40** × Ⓐ at 1/s on the title, then one each of START, B, BACK, X, Y | title, unchanged |
+| G | Ⓐ every 4 s through the whole boot (88 presses) | permanent **black screen**, no crash, never recovers |
+
+In run F every press was delivered — the driver logs `keystroke vk=5800 down/up`
+for each — and the new `[RE-INPUT]` line never fired, so nothing was swallowed.
+The guest received them and ignored them. **No button does anything** on that
+title: START, B, BACK, X and Y are as inert as Ⓐ
+([`captures/title-unresponsive-attract.png`](captures/title-unresponsive-attract.png)).
+
+Run G is worth its own warning: hammering Ⓐ through the boot is not merely
+useless, it **breaks the run** — 88 presses left a black screen that never came
+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.
+
 ## Still open
 
-Why the acceptance is intermittent. The next step is not another guess: capture
-the *first* title's Ⓐ under `--cache_throw_diag`-style logging of the guest's own
-state machine, or simply script "tap Ⓐ once per second for 30 s on the first
-title" and see whether the success rate goes to 1 — a cheap, honest experiment
-that also gives a reliable route to the main menu for the UI paint-order work.
+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.