docs/re: the boot-title recipe is 3/3 without my capture flag and 0/5 with it — and confounded

Using last iteration's recipe (first title, one (A)) four more times, it failed
every time. The nine-run table splits perfectly on --log_ui_draws: 3 of 3
successes without it, 0 of 5 with it. That would indict my own instrumentation
cvar, which is the one that captures paint order.

It is also perfectly confounded and the entry says so rather than picking the
exciting reading: every success had its title inside 147 s, every failure at
177 s or later. Flag and boot-time move together across all nine runs. A
mechanism is hard to see for the flag (it is read only when F10 arms a capture;
the per-draw hook is one relaxed atomic load), which argues for the boot-time
story — but "I cannot see how" is not evidence.

The separating experiment is named: ON runs with a fast boot. One that accepts
(A) exonerates the flag.

Also recorded: widening the menu signature last commit made screen_id classify
some boot frames as "menu", twice in one run before any menu existed. A dark-blue
movie frame and this menu are not separable from a single grab — navigation
scripts need the classification to hold across two grabs, which is a caller-side
fix, not a classifier one.

docs/re/BACKLOG.md

@@ -171,8 +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. **Now routine**: the title that ends the boot sequence accepts a single Ⓐ (2 of
+"Ⓐ is dead" reading is withdrawn. **Not routine after all** — see the 2026-08-19 table in
-2 runs); the title the attract loop returns to accepts nothing (Ⓐ, START, B,
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md): 3 of 3
+successes without `--log_ui_draws` and 0 of 5 with it, perfectly confounded with
+how long the boot took (every success ≤147 s, every failure ≥177 s). Until that
+is separated, capturing a screen *and* navigating to it in the same run is not
+dependable. The earlier claim, kept: the title that ends the boot sequence
+accepts a single Ⓐ (2 of 2 at the time); 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

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

@@ -158,3 +158,50 @@ 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.
+
+## 2026-08-19 — the "first title accepts Ⓐ" rule is weaker than stated, and there is a confound
+
+The entry above says the boot title accepts a single Ⓐ, 2 of 2. Continuing to
+use that recipe, it failed four times running. The full record, every run with
+the press verifiably delivered:
+
+| run | `--log_ui_draws` | title appeared at | Ⓐ |
+|---|---|---|---|
+| crash-dir | off | ~83 s | **menu** |
+| boottitle | off | 147 s | **menu** |
+| A/B "off" | off | — | **menu** |
+| menucap 1 | on | 292 s | no (40 taps) |
+| menucap 2 | on | 177 s | no |
+| optcap 1 | on | 241 s | no |
+| optcap 2 | on | 219 s | no |
+| A/B "on" 1 | on | never (black screen) | — |
+| A/B "on" 2 | on | 186 s | no |
+
+**3 of 3 without the flag, 0 of 5 with it.** That is a strong correlation, and it
+points at *my own instrumentation cvar* — which would be a serious finding, since
+`--log_ui_draws` is what captures the paint order in the first place.
+
+**It is also completely confounded, and the table shows it.** Every success had
+its title inside 147 s; every failure had it at 177 s or later. Flag and
+boot-time are perfectly correlated across these nine runs, so this evidence
+cannot separate "the capture cvar breaks input" from "a title that arrives late
+is already in the attract state and does not accept input". Both stories fit all
+nine rows.
+
+**A mechanism is hard to see for the flag**: `log_ui_draws` is read only when F10
+arms a capture; the per-draw hook is one relaxed atomic load, and the swap hook
+another. Nothing there should reach the guest. That argues for the boot-time
+reading — but "I cannot see how" is not evidence, and the correlation is what was
+measured.
+
+**What would separate them**, cheaply and next: run the flag ON several times and
+record (boot time → outcome). A single ON run whose title arrives inside 147 s
+and which then accepts Ⓐ exonerates the flag outright.
+
+### A defect I introduced, recorded rather than left to bite
+
+Widening the menu signature (previous commit) made `screen_id.py` classify some
+**boot/attract frames** as `menu` — twice in one run, at t=54 s and t=146 s, long
+before any menu exists. The menu and a dark-blue movie frame are not separable
+from a single grab. Scripts that navigate on this must require the classification
+to hold across two grabs a second apart; the classifier itself cannot fix it.