backlog: record the WaitMultiple withdrawal, the 30/30 read, and the missing freeze

docs/re/BACKLOG.md

@@ -746,6 +746,31 @@ search cannot find a *schedule*.
   `/proc/maps` classification + `x/8gx` **never booted** (`EMULATOR GONE at 0s`,
   stale emulator/lock from the prior gdb session), so that check and the **frozen**
   capture are still unrun.
+* ✅ **(2026-08-25) WITHDRAWN: the 8 "unrestorable rbx" reads were `WaitMultiple`.**
+  `rbx` was restored fine on all 18. The backtrace grep matched `XObject::Wait`
+  as a **substring**, so `WaitMultiple` frames were pooled in and read with the
+  wrong rule — `Wait` keeps `this` in rbx (`8fbc90: mov %rdi,%rbx`) but
+  `WaitMultiple` keeps the **`XObject**` array** (`8fbfc0: mov %rsi,%rbx`), so
+  `[rbx]` there is `objects[0]`, an object pointer needing a **second** deref.
+  Confirmed live: re-reading with the matching rule per frame resolves
+  **30/30 objects across 23 wait frames, nothing unresolved** —
+  **XEvent 20 / XSemaphore 9 / XTimer 1** (`data/waitobj-s02.txt`). `XTimer` was
+  invisible before because its only thread is a `WaitMultiple` one. Every
+  `WaitMultiple` thread waits on a **pair**; T78/79/80 and T64/65 are worker
+  groups sharing a handle. 🟡 `%ebp` is **not** a usable count — `WaitMultiple`
+  reuses it at `8fc158` — so the array is bounded by reading until an entry stops
+  resolving. What survives: the object types and the self-validating read.
+* 🔴 **(2026-08-25) The frozen capture is STILL unrun — the freeze did not happen.**
+  Two captures in one run (200 s and 367 s of mission), and `screen_id` reads
+  **`flight`** at both, plus at ~470 s with a drifting frame mean. So the labelled
+  `healthy -> frozen` diff is **two healthy captures**, and its `20 -> 18` is three
+  threads exiting, not a freeze. 🟡 **This also questions the "~270 s black-screen"
+  bound** these runs are planned around — confound not ruled out: gdb slows the
+  emulator (boot to title took 207 s), so 470 s wall-clock may be far short of
+  270 s *guest* time. **Next: reach the freeze by its actual trigger rather than a
+  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.
 * ~~🚧 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**.