docs: the freeze entry gets a measurement instead of a plan

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

docs/re/BACKLOG.md

@@ -316,10 +316,16 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
   per cycle by design. ✅ What is established instead: the guest is **spinning,
   not deadlocked** — over 10 s while frozen the main thread is in state `R`
   gaining 409 ticks, guest threads ~680 in total, and **not one kernel call** is
-  made. So it is guest code waiting on guest memory. **Next: which guest PC** —
-  a Canary diagnostic that dumps each `XThread`'s PPC PC on demand, then
-  `sylpheed.db` to name the function. That is a `build-canary` plus a
-  reproduction. `frozen.py` detects the state in one call; `ob_hunt.py` /
+  made. So it is guest code waiting on guest memory. ✅ **Seen from inside** (2026-08-24, gdb): all **79** threads are in a
+  **wait** — guest threads in `KeWaitForSingleObject`/`NtWaitForSingleObjectEx`,
+  the GPU processor idle, the main thread in `poll()` — while the process still
+  burns **1 253 ticks / 10 s**, 403 of them in the **TimerQueue** thread and
+  ~280 each in two guest threads the backtrace shows *blocked*. So they are
+  **cycling through a timed wait**, and the CPU burn is in the kernel layer's
+  wait path, not in guest code. No Canary build was needed: `XENIA_BIN` pointing
+  at a gdb wrapper keeps the lockfile and satisfies `ptrace_scope=1`.
+  **Next:** read *which* object those two threads wait on and find who should
+  have signalled it. `frozen.py` detects the state in one call; `ob_hunt.py` /
   `ob_flag.py` abort on it. **Roughly two runs in three.**
   See [`mission-freeze-resume-spin.md`](mission-freeze-resume-spin.md).