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

docs/re/title-crash-stl-tree.md

@@ -346,3 +346,44 @@ The cache directory is currently **40 MB**, and the tree still carries
 so it is quite possibly incomplete. Letting the game build a complete cache and
 re-running the tutorial is one boot to warm and one to test, and it would say
 whether the mission path is blocked by the crash at all or only by cache state.
+
+
+## 🔴 Refuted: completing the on-disc cache does not stop the mission crash (2026-08-19)
+
+This page's own reproduction — move the cache aside, get a throw ~100 s in;
+restore it, get none — made "the cache is incomplete" the obvious explanation for
+the mission-path crash. It is not the cure. Three tutorial runs, measured:
+
+| run | cache state | crashes early | storm begins | total dumps |
+|---|---|---|---|---|
+| `tut2` | subdir `6` **missing** | 641 by t+24 s | ~t+24 s | 13 243 |
+| `tut3` | missing → **gained `6`** during the run | **2** through t+80 s | ~t+96–112 s | 11 898 |
+| `tut4` | `6` present from the start | **2** through t+56 s | ~t+56–88 s | 11 497 |
+
+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 in all three runs is `PC: 0x82307128` — one
+address, no others.
+
+So the cache is not what gates this. It may be what gated the *boot-time* throw
+this page originally documented; it does not gate the mission one.
+
+### ✅ What the runs did give: a usable window
+
+Both post-cache runs show the same shape — **exactly 2 crashes, then nothing, for
+56–80 seconds after the mission starts** — where the first run was already at 641
+by t+24 s. The mission renders and advances during it.
+
+That is the practical opening for the thing this crash has been blocking: the
+**second capital-ship capture** needs `F10` armed *inside* that window, not after
+it. It is not a guarantee — the storm began at t+24 s, ~t+96 s and ~t+56 s across
+the three runs, so the window varies and a run can lose it entirely — but two of
+three runs offered most of a minute of clean mission time.
+
+### What is still not settled
+
+* 🔴 What actually triggers the storm. Not the cache; not input; the crash PC is
+  invariant.
+* ❔ What the 2 early crashes are, as distinct from the storm.
+* ❔ Whether a capture taken inside the window is complete enough to be useful —
+  untried.