docs: point the freeze item at the targeted log line rather than the global flag

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

docs/re/BACKLOG.md

@@ -324,8 +324,13 @@ is what the autopilot needs in order to CHOOSE a target. One run in:
   **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` /
+  🔴 **Reading the wait target from the log is blocked by cost**:
+  `KeWaitForSingleObject` is `kHighFrequency` and silent without
+  `--log_high_frequency_kernel_calls=true`, and *with* it the emulator is 17
+  minutes into a boot with a **black screen** and 175 MB of log. **Next, cheapest
+  first:** a targeted Canary log line that fires only after a wait has timed out
+  N times on the same thread — self-selecting, free on a healthy run, one small
+  patch plus a build that is already configured. `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).