re: measure the boot-nav title gate — and withdraw my own diagnosis

Last iteration I said launch_mission died because skip_intro only tests for
the title on a static frame, gated at rmse <= 1500, and that run logged 1503
and 1549 just above the cut. I also said the fix was NOT to nudge 1500 but
to measure both signals through a boot first. Measured, and the diagnosis
does not survive.

boot_trace.sh logs the two signals skip_intro decides on -- frame-to-frame
RMSE and the is_title.py green-glyph count -- through a clean boot with no
presses at all. One run, 29 samples over 484 s:

  8 samples had rmse <= 1500, so the gate OPENED eight times
  0 samples had glyph > 0, so the title was never seen

At t=145 s the RMSE was 1205, comfortably inside the threshold, and the
glyph test was called and answered zero. A frame can be perfectly static
without being the title -- the intro movie has long quiet stretches, three
reading RMSE exactly 0. So 1503/1549 were almost certainly movie frames too,
and raising the constant would have admitted two more of them.

What is left is narrower and honest: the interactive title never appeared,
rather than appearing and being missed by a threshold.

The limitation is recorded rather than buried: the tracer intended 1 s
sampling and achieved 16.9 s, because each iteration forks two screenshots,
ImageMagick compare and a fresh Python. So this does NOT prove the title
never appeared -- only that it was absent from 29 samples. A window shorter
than ~17 s falls between them. The recorded next step is to make the tracer
sample at the rate it claims before concluding anything stronger.

Artifact: docs/re/captures/boot-signal-trace.tsv.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/BACKLOG.md

@@ -1033,25 +1033,31 @@ premise was wrong.**
   Candidates: the **7 `.embsec_` sections** (VAs 0x84D0000–0x86AC000, ~129 KB
   total, executable) or a hashed record in `hidden/MiscBin.pak`. **Finding it
   gives the actual per-phase clear condition for every stage.**
-* 🚧 **(2026-08-25) BLOCKED — the live test of the `reset_phase_threads` rename
-  never got to run, because boot-nav cannot reach the title.** The experiment is
-  ready and worth doing: built-in 100 clears the trigger container and frees
-  every thread but the caller, so at a phase terminator **both**
-  `[phase+272+20]` (triggers queued) and `[phase+216+8]` (coroutines alive)
-  should collapse; if they climb straight through a phase boundary instead, the
-  reading is wrong. `tools/re-capture/phase_watch.py` now prints both counters —
-  **written this session but never yet exercised against a live guest.**
-  **The blocker, measured:** `skip_intro.sh` only tests for the title when the
-  frame is static, gated at `rmse <= 1500`. A 381 s run produced 18 "waiting it
-  out" samples, and two of them — **1503 at 104 s and 1549 at 139 s** — sat just
-  above the cut, so `is_title.py` was never even called and the single allowed
-  press was never spent. The attract loop then restarts and the wait never ends.
-  ▶️ **First step, and it is NOT "raise the constant":** log `rmse` *and* the
-  `is_title.py` glyph count every second through a boot, so the true-title and
-  attract-demo distributions can be seen; only then decide the gate. Tuning 1500
-  to make one run pass would be fitting to a single sample. Note the surrounding
-  comments are emphatic that tapping through the movies is what breaks the
-  title, so the press budget really is one.
+* ❌ **(2026-08-25) My own boot-nav diagnosis, MEASURED AND WITHDRAWN.** I said
+  the run died because `skip_intro.sh` gates the title test at `rmse <= 1500`
+  and the run logged 1503/1549, just above the cut. Measured over a clean
+  no-press boot ([`boot-nav-title-gate.md`](boot-nav-title-gate.md),
+  `captures/boot-signal-trace.tsv`): the gate **opened eight times** in 29
+  samples, and at `t=145 s` the RMSE was **1205** — inside the threshold — with
+  `is_title.py` answering **0 glyph pixels**. The glyph count was 0 in *all* 29
+  samples over 484 s. A static frame is not the title; the intro movie has long
+  quiet stretches, three of them reading RMSE exactly 0. So the gate is not what
+  stopped it, and raising the constant would have admitted two more movie frames.
+  🟡 Narrowed: **the interactive title never appeared**, rather than appearing and
+  being missed. ❔ **But the run does not prove that** — the tracer intended 1 s
+  sampling and achieved **16.9 s** (two screenshots + ImageMagick `compare` + a
+  fresh Python per iteration), so a title window under ~17 s falls between
+  samples. ▶️ First step: make the tracer sample at the rate it claims — one
+  long-lived Python process computing both signals — then re-run. Second: check
+  whether the fast 2026-08-25 run had a warm shader cache that this one, started
+  after `rm -f /dev/shm/xenia_*`, did not.
+* 🚧 **(2026-08-25) STILL UNRUN — the live test of the `reset_phase_threads`
+  rename.** Built-in 100 clears the trigger container and frees every thread but
+  the caller, so at a phase terminator **both** `[phase+272+20]` (triggers
+  queued) and `[phase+216+8]` (coroutines alive) should collapse; if they climb
+  straight through a phase boundary instead, the reading is wrong.
+  `tools/re-capture/phase_watch.py` prints both — **written, still never
+  exercised against a live guest.** Blocked behind the boot-nav item above.
 * 🟡 **(2026-08-25) The legacy IDXD string-pool reader is wrong far more often
   than assumed** — now measurable for the first time, since the record table gives
   a ground truth. Verified by hand: `FCSRange` (the module doc's own canonical