docs+tools: the threading fix measured 5/5 against 1/5, and a driver lock

resume_reliability.sh counts, per boot, whether the title's loader thread became
the CALLER of a kernel call. Counting boots where the press reached the title:
before the fix 1 of 5 ran the loader; after it, 5 of 5. Three of the post-fix
boots were driven far enough to classify the screen and all three reached the
MAIN MENU, each with the same shape - title at 216-252s, 40 kernel calls by the
loader, 6 ResolvePath reads. The failing boots before had zero of both, every
time.

Caveat kept in the doc: pre-fix runs were interleaved with compiles and a race is
load-sensitive, so the counts corroborate the mechanism rather than carry it.

Also fixes a self-inflicted confound. Two runs came back 'title_at_s=none' with
the emulator log ending in 'Killed', which I first read as the title detector
being too strict. It was not: an earlier copy of the script was still running
because 'pkill -f resume_reliability.sh' had matched the shell running it rather
than the script, and each of that copy's iterations kills the emulator BY NAME -
outside run-canary's lockfile. The harness now takes its own lockfile and refuses
a second copy, and the note records that pkill -f matches your own shell.

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

@@ -577,12 +577,31 @@ On the first clean boot afterwards, the same loader thread is the **caller** on
 boot before the fix had exactly **zero** of both. That is the predicted change,
 and it is the strongest evidence available short of a reliability run.
 
+### Measured: 5 of 5 after, against 1 of 5 before
+
+`tools/re-capture/resume_reliability.sh` boots repeatedly and records, per boot,
+whether the loader thread was created and whether it ever became the **caller**
+of a kernel call. Counting only boots where the press actually reached the title:
+
+| | boots | loader ran | reached the main menu |
+|---|---|---|---|
+| **before** the fix | 5 | **1** | 1 |
+| **after** | 5 | **5** | 3 (the others were not driven that far) |
+
+The three post-fix boots that were driven on all show the same shape: title
+detected at 216–252 s, loader thread created, **40** kernel calls by it, **6**
+`ResolvePath` asset reads, screen classified `menu`. Before the fix the failing
+boots had **zero** of both, every time.
+
+⚠️ One caveat worth keeping: the pre-fix runs were interleaved with compiles and
+other load, and a race is load-sensitive. The post-fix runs were not. The
+mechanism is read directly from the code, which is what carries the conclusion;
+the counts corroborate it.
+
 ### What is honestly not shown
 
-* 🟡 **That boots now reach the menu reliably.** The post-fix boot drifted into
-  the attract loop because `skip_intro.sh` fired its single press at 145 s, and
-  the run before it pressed on the **SQUARE ENIX publisher logo** — see below. A
-  clean before/after reliability count still needs several boots.
+* 🟡 A larger sample. Five boots each way is enough to act on, not enough to
+  quote a rate.
 * ⚠️ **`host resume was refused` is not by itself a defect.** Resuming a thread
   that is not suspended legitimately returns false, and the log fires ~7 times in
   a normal boot. It is a breadcrumb, not an alarm.
@@ -601,3 +620,26 @@ and it is the strongest evidence available short of a reliability run.
 Now `tools/re-capture/is_title.py` **counts** the green glyph over the whole
 frame — geometry-independent and specific. Measured: **0** pixels on the SQUARE
 ENIX logo, **1 520** on a real title, threshold 400.
+
+
+## ⚠️ One emulator at a time has to mean one *driver* at a time (2026-08-19)
+
+The first reliability batch reported `title_at_s=none` on two runs, with the
+emulator log ending in `Killed`. That was read at first as the title detector
+having been tightened too far. **It was not.**
+
+An earlier copy of `resume_reliability.sh` was still running: the `pkill -f
+resume_reliability.sh` meant to stop it had matched the *shell running the
+command* instead (exit 144) and killed that, leaving the script alive. Each of
+its iterations begins by killing the emulator **by name** — which is outside
+`run-canary`'s lockfile — so it kept shooting the newer batch's boots.
+
+Two lessons, both cheap:
+
+* `pkill -f <script>` matches your own shell. Use `pkill -x <script>`.
+* The lockfile protects the emulator, not the harness. `resume_reliability.sh`
+  now takes `/tmp/resume-reliability.lock` and refuses to start a second copy.
+
+The evidence recovered cleanly once the interference stopped — the interrupted
+batch's own run 3 had already reached the menu with the same 40 calls / 6
+`ResolvePath` signature.

docs/re/captures/resume-fix-reliability.csv

@@ -0,0 +1,5 @@
+run,title_at_s,thread_created,thread_ran_calls,resolvepath_after,screen
+1,none,0,0,0,other
+2,none,0,0,0,other
+3,216,1,40,6,menu
+4,252,1,40,6,menu