docs: withdraw the resume-refused lead - kHighFrequency waits are simply unlogged

The 1663 refused resumes on thread F80001D8 looked like a second lost resume of
the kind fixed earlier today. They are not.

That thread DID execute - the log carries its XThread::Execute line, guest entry
82FFE6C0 - and then 137000 lines of silence. The silence proves nothing:
KeWaitForSingleObject and NtWaitForSingleObjectEx are declared kBlocking,
kHighFrequency, and PrintKernelCall skips every kHighFrequency export unless
--log_high_frequency_kernel_calls=true, which defaults to false. A thread parked
in a wait is invisible in these logs.

So the boring reading is the right one: the guest kicks a worker that is blocked
ON AN OBJECT, and Resume returns false because the thread is not SUSPENDED. That
is what a refused resume means, exactly as suspected before the count made it
look interesting.

Method note kept in the doc, because it is the reason one conclusion survives and
the other does not: the title-loader finding rested on 00:00:00 host CPU time
from ps -L and on the fix changing behaviour 5/5 against 1/5 - not on log
silence. In this codebase log silence alone is never sufficient evidence that a
thread is idle.

Also records a grep error of mine that briefly produced "zero kernel calls,
ever": the pattern ^[dikwF!]> missed the K> kernel prefix. Caught before it was
written down, and it changed the conclusion.

docs/re/BACKLOG.md

@@ -767,9 +767,13 @@ guest C++ throw — identical frames 6 s apart, no new dumps, 400 % CPU. So the
 blocker moved from "cannot reach a mission" to "the mission freezes". Cheapest
 next test: the crash page shows a **complete on-disc cache produces no throw**,
 and the cache is only 40 MB with `.partial`/`.cold-rebuilt` leftovers nearby —
-one boot to warm it, one to re-test. New lead recorded there too: the
-resume-refused diagnostic fires 1 671 times on this path, 1 663 on one thread,
-against ~7 on the menu path — specific, and explicitly not yet claimed as a bug.
+one boot to warm it, one to re-test. 🔴 The resume-refused lead (1 663 on one
+thread) is **REFUTED**: that thread did execute, and `KeWaitForSingleObject` /
+`NtWaitForSingleObjectEx` are `kHighFrequency`, which is unlogged unless
+`--log_high_frequency_kernel_calls=true` — so a parked thread is invisible and
+the refusals are just the guest kicking a worker blocked on an object. Method
+note: the title-loader finding rested on **host CPU time**, not log silence,
+which is why it stands and this did not.
 
 What blocked it before was **the cache-flush crash**, not navigation — measured
 2026-08-19. `tools/re-capture/tutorial_launch.sh` (which retries whole boots,