docs: the resume-spin lead is refuted by its own control, and the freeze is a guest-side spin

The control this file never had: a run with the Kernel channel on, analysed WHILE
STILL FLYING, has 2738 refused resumes on one pair - more than the frozen run's
1171. The target's own lines show why. The game runs a self-suspending worker
(NtSuspendThread on itself, a manager thread resumes it, thousands of times), and
a self-suspended thread is not host-suspended, so the host Resume legitimately
returns false EVERY cycle: 3115 refusals against 3115 resumes.

The error is named rather than buried: the warning's commit says "~7 times in a
normal boot" and this file generalised that from boot to gameplay, where the
number is thousands. The 150x anomaly was an artefact of the baseline. The
zero-CPU threads go with it - the healthy run has four of those too.

What the instrumented reproduction DOES establish is sharper than the lead was.
The last kernel event in 690000 lines is "Thread F8000204 self-suspending", with
self-suspends 3116 against resumes 3115 - but the resumer never issues another
NtResumeThread at all, so nothing was dropped in flight; every thread stopped
together. And the guest is SPINNING, not deadlocked: over 10 s while frozen the
main thread is in state R gaining 409 ticks and guest threads gain ~680 in total
while making not one kernel call. So it is guest code waiting on something in
guest memory, and the next question is which guest PC.

Two corrections fall out: "the log stopped growing" is not a freeze detector (it
goes quiet for 25 s in normal flight), and 0xbdb59668 held the counter again -
4 of 6 runs now.

freeze_report.py makes the analysis repeatable, and refuses to answer "did this
thread ever run" when the Kernel channel was off rather than reporting a false NO.

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

docs/re/captures/stage02-freeze-cpu-while-frozen.txt

@@ -0,0 +1,18 @@
+# CPU gained per host thread over 10 s while the game is FROZEN
+# ticks state tid comm
+   409 R   47682 xenia_canary
+    57 S   47745 XThread7EFFE6C0
+    56 S   47746 XThread7D7FC6C0
+    37 S   47684 Logging Writer
+    20 S   47758 XThread63FFF6C0
+    14 S   47762 XThread42FFE6C0
+    14 S   47761 XThread43FFF6C0
+    14 S   47760 XThread51FFD6C0
+    10 S   47714 GPU Commands (0
+     3 S   47752 SDLAudioP2
+     1 S   47747 XThread7C7FB6C0
+     1 S   47715 GPU Frame limit
+     0 S   50534 XThreadFFFFF6C0
+     0 S   50533 XThread11FFD6C0
+     0 S   50532 XThread1FFFF6C0
+# total ticks gained: 636 (100 ticks = 1 s of CPU)

docs/re/captures/stage02-freeze-kernel-tail.log

@@ -0,0 +1,25 @@
+# Stage 02, frozen at TIME 03:37.83, Canary log with the Kernel channel ON
+# (LOG_MASK=12 LOG_LEVEL=3). 50 MB / 690k+ lines; this is the tail.
+#
+# counts for the self-suspending worker F8000204:
+#   'self-suspending'                          3116
+#   'resumed'                                  3115
+#   NtResumeThread refusals from F800026C      3115
+# so exactly ONE self-suspend is unmatched - the last one - and no
+# further NtResumeThread is ever issued for it.
+
+d> F8000204 Thread F8000204 resumed
+d> F8000204 NtSuspendThread(F8000204, 70AAFE50(00000000), ContextArg)
+d> F8000204 Thread F8000204 self-suspending
+d> F800026C NtResumeThread(F8000204, 70B6FBF0(00000000))
+w> F800026C XThread::Resume: host resume was refused for thread F8000204
+d> F8000204 Thread F8000204 resumed
+d> F8000204 NtSuspendThread(F8000204, 70AAFE50(00000000), ContextArg)
+d> F8000204 Thread F8000204 self-suspending
+--- final lines of the file ---
+d> F80000A0 ObReferenceObjectByHandle(FFFFFFFE, 30000000, 7071FDC0(00000000))
+d> F80000A0 KeSetBasePriorityThread(30071010, 00000001)
+d> F80000A0 ObDereferenceObject(30071010, ContextArg)
+d> F8000204 Thread F8000204 resumed
+d> F8000204 NtSuspendThread(F8000204, 70AAFE50(00000000), ContextArg)
+d> F8000204 Thread F8000204 self-suspending