docs: note that catching a freeze is a per-run lottery, and the watcher that waits for it

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

docs/re/BACKLOG.md

@@ -333,8 +333,11 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
   500. **Healthy-run control measured** — 27 lines over 25 minutes, all one
   thread polling one Event at guest VA `BE56BB5C` with a ~30 ms timeout, so the
   freeze signal is a **new (thread, object) pair**, not the presence of output.
-  🟡 **Next:** catch a freeze with it — the run that measured the control never
-  froze. `frozen.py` detects the state in one call; `ob_hunt.py` /
+  🟡 **Next:** catch a freeze with it. Two 25-minute runs in a row did **not**
+  freeze (the control is therefore measured twice: 27 and 24 lines, same single
+  pair), and the earlier freezes came in a cluster — so this is a ~30-minute
+  lottery per run rather than a dependable step. `freeze_watch.sh` waits for one
+  unattended and snapshots the probe at the moment it lands. `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).