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
-2 runs); the title the attract loop returns to accepts nothing (Ⓐ, START, B,
+"Ⓐ is dead" reading is withdrawn. **Not routine after all** — see the 2026-08-19 table in
+[`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