backlog: frozen capture taken, screen_id correction, instrument-provokes-freeze at n=1

docs/re/BACKLOG.md

@@ -771,6 +771,35 @@ search cannot find a *schedule*.
   clock, or measure guest time under gdb so the wait is set in the right units.**
   Chaining Bash calls **within one turn** works and is no longer the limit — the
   emulator survives between calls; this run spent ~900 s across three.
+* ✅✅ **(2026-08-25) FROZEN CAPTURE TAKEN — and the per-thread diff is the result.**
+  `freeze_waitobj.sh` split into `boot`/`watch`; `watch` waits for the **event**
+  (`frozen.py` + `in_flight`) instead of sleeping a guessed interval, and caught
+  it first try. Hard stop, not a hitch: a frame minutes later is
+  `max_pixel_delta=0` against the capture. Same run, same mission
+  (`data/waitobj-s02.txt`): **20 → 24 wait frames**, XEvent **19 → 23**,
+  XSemaphore **8 → 7**, XTimer 1 → 1. 🔑 **17 of 24 threads sit on the EXACT
+  object they were already on** — so this is *not* a whole-emulator stall. What
+  moves: T105/T67/T68 park on `Wait(XEvent)` and T69 on `Wait(XSemaphore)` having
+  been running; **T74 and T75 move off a semaphore onto an event** (the only
+  threads that change what *kind* of object they wait for → chase these first);
+  T50 drops `WaitMultiple(XEvent,XEvent)` → `Wait(XEvent)`.
+* ✅ **(2026-08-25) CORRECTION: `screen_id == flight` is NOT a freeze test.**
+  The previous entry used it to rule out a freeze. `frozen.py` exists precisely
+  because a frozen mission still classifies as `flight` (its docstring: 724 s of
+  identical state, 212 % CPU, classifier happy). Re-testing the saved frames says
+  that run was genuinely healthy — right, but by luck. **And the "~270 s
+  black-screen" bound those runs were planned around is not a thing**: the freeze
+  does not black the screen and keeps no clock (onsets 27/45/83/183/255 s).
+* 🟡 **(2026-08-25) One data point that OUR INSTRUMENT provokes the freeze.**
+  Run flew **~670 s clean** with only the pilot; a heavy-CPU inducer
+  (`heavy_read.py cpu`) started at 08:59:54 and it froze at **09:00:48 — 54 s
+  later**, inside the 27–255 s band. Consistent with the existing tally but
+  **n=1, not causal** (confounder: elapsed mission time). ✅ **Refuted en route:
+  the I/O was never the cost** — a full uncapped walk of every allocated extent is
+  **371 MB in 0.1 s**, all page cache; the expense is Python-level CPU, ~4.2 s a
+  pass. **Settle it with:** alternating inducer-on/off windows within a run,
+  several runs, compared per unit of *mission* time — cheap now `watch` is
+  event-driven.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.