re: the phase transitions -- and withdrawing yesterday's refutation

because the test probed the wrong state

Nine stores to the phase field this+132, control-gated on the 136 query
returning at least the 18 known ones. Attributed to the handler each
lives in, they give the phase graph: entry -> 2, then 2 -> 0 (splash),
2 -> 3, 3 -> 4, and 4 -> 2 on event 0.

That last edge is the problem with what I did last iteration. The event-0
block sets TWO fields one instruction apart -- stw r28,136(r30) for state
0 and stw r11,132(r30) with r11 = 2 for phase 2. So B from the menu lands
in PHASE 2, the same phase as the boot title, and the test I ran
believing it probed phase 4 state 0 probed nothing of the kind.

So the refutation is withdrawn. Worse for me and better for the idea: A
working on the B-returned title is exactly what the hypothesis predicts,
since phase 2 is the phase that references BUTTON. The hypothesis is back
to untested, now consistent with two observations rather than one, and
what it still needs is the attract-returned title's phase -- which no
test so far has read.

The measurement from that iteration stands, because it does not depend on
the phase: the B-returned title accepts A, so only the ATTRACT-returned
title is inert. I have said so explicitly in the page rather than letting
the withdrawal take the good half down with it.

METHOD gets the lesson: before testing "state X behaves like this", check
your route actually reaches state X. When a transition writes more than
one field, read the whole block and not just the store you were looking
for.

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

@@ -660,7 +660,7 @@ state 0 (`sub_821C6458`). Same screen, different code. See
 **Candidate:** the boot title is phase 2; the attract-returned title is phase 4
 state 0; only one of them wires up Ⓐ.
 
-### 🔴 Tested the same day — and the candidate is dead
+### ⚠️ Tested the same day, and the TEST was invalid — see the withdrawal below
 
 There was a cheaper test than reading `this+132`: the state graph says Ⓑ from the
 main menu goes `4 → 0`, so **the Ⓑ-returned title *is* phase 4 state 0**. If phase
@@ -673,12 +673,18 @@ main menu goes `4 → 0`, so **the Ⓑ-returned title *is* phase 4 state 0**. If
 | *control* — Ⓐ on the boot title | → main menu ✅ |
 | Ⓐ on the **Ⓑ-returned** title | → **main menu** ✅ |
 
-So phase 4 state 0 does wire up Ⓐ, and "the boot title is phase 2, the returned
-title is phase 4 state 0, only phase 2 handles Ⓐ" is **refuted**. (Conditional on
-the graph reading that Ⓑ lands in state 0 — that edge is decoded, but which
-*title* it produces is my inference.)
+**🔴 Withdrawn.** Reading the event-0 block in full shows it sets **two** fields,
+one instruction apart: `stw r28, 136(r30)` (state = 0) *and* `stw r11, 132(r30)`
+with `r11 = 2` — **phase = 2**. So Ⓑ lands in **phase 2**, the same phase as the
+boot title, and this test never probed phase 4 state 0 at all.
 
-### ✅ What the test did establish — the puzzle is narrower than this page says
+The refutation is withdrawn. Ⓐ working on the Ⓑ-returned title is exactly what
+the hypothesis predicts — phase 2 is the phase that references `BUTTON`.
+
+### ✅ What the test DID establish — the puzzle is narrower than this page says
+
+(This part stands: it is a measurement, independent of which phase the returned
+title turns out to be.)
 
 This page frames the problem as *the boot title accepts Ⓐ, a later title does
 not*. That is too broad. **The Ⓑ-returned title accepts Ⓐ perfectly well** — a