docs: the cache is refuted as the mission-crash cure, and a usable window found

This page's own reproduction - move the cache aside, get a throw; restore it, get
none - made "the cache is incomplete" the obvious explanation for the mission
crash. Three tutorial runs say otherwise.

  tut2  subdir 6 MISSING              641 crashes by t+24s   13243 total
  tut3  missing -> gained 6 in-run      2 crashes to t+80s   11898 total
  tut4  6 present from the start        2 crashes to t+56s   11497 total

The missing entry was real: \aab216c3\6 was requested and absent, and the game
wrote it during tut3 (11 -> 12 files). tut4 then ran with a complete cache and
stormed anyway. Every dump across all three runs is PC 0x82307128, one address,
no others. So the cache may gate the boot-time throw this page documents; it does
not gate the mission one.

What the runs did give is an opening. Both post-cache runs show the same shape -
exactly 2 crashes, then nothing, for 56-80 seconds of rendering, advancing
mission - where the first run was already at 641 by t+24s. That is where the
second capital-ship capture has to happen: F10 armed INSIDE the window. Not a
guarantee, since the storm began at t+24s, ~t+96s and ~t+56s across the three
runs, but two of three offered most of a minute.

docs/re/BACKLOG.md

@@ -764,10 +764,12 @@ fix, `tutorial_launch.sh` drives boot → title → menu → TUTORIAL and the mi
 **loads and renders** (flight HUD, "Go to the box on your screen"). It then
 freezes under 13 243 crash dumps, all at `0x82307128`, preceded by exactly one
 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. 🔴 The resume-refused lead (1 663 on one
+blocker moved from "cannot reach a mission" to "the mission freezes". 🔴 **The cache is REFUTED as the cure** (3 runs): the
+missing entry `\aab216c3\6` was real and got written, and the run with a complete
+cache stormed anyway — 11 497 dumps, all `0x82307128`. ✅ **But a usable window
+exists:** both post-cache runs ran the mission with exactly **2 crashes for
+56–80 s** before the storm, where the first run was at 641 by t+24 s. The ship
+capture needs `F10` armed *inside* that window. 🔴 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