docs: the mission path is reachable now - it freezes there instead of dying earlier

The backlog has said a second capital-ship capture needs the 0x82307128 crash
dealt with first, because the run died at SELECT DATA before any mission
existed. That is no longer where it stops. With the Canary threading fix making
the menu dependable, tutorial_launch.sh drives boot -> title -> menu -> TUTORIAL
and the mission LOADS AND RENDERS: flight HUD, "Go to the box on your screen",
warship counters, controller diagram.

It then freezes. 13243 crash dumps, every one at PC 0x82307128, guest thread 9,
Access Violation read at 0x10000000C, preceded by exactly ONE
RtlRaiseException(E06D7363) right after a HostPathDevice::ResolvePath() with
empty arguments - the cache-flush shape. Two screenshots 6s apart are identical
(RMSE 0), no new dumps accumulate, and the process still burns 400% CPU.

So: reachable, renders, unusable for a capture. The blocker moved rather than
lifted, which is worth recording precisely because the entry's stated reason is
now wrong.

One new lead, deliberately not claimed as a cause: the resume-refused diagnostic
added with the threading fix fires 1671 times on this path and 1663 of them are
the SAME thread, F80001D8, with 152 before the first crash - against about 7 on
the menu path. Resuming a non-suspended thread legitimately returns false and
"Resume to kick a worker" would produce exactly this, so it is a lead, not a bug.
It is cheap to settle: check whether that thread makes kernel calls between
refusals.

Cheapest next test named: this page already shows a COMPLETE on-disc cache
produces no throw at all, and the cache is 40MB with .partial/.cold-rebuilt
leftovers beside it. One boot to warm, one to re-test.

docs/re/BACKLOG.md

@@ -759,7 +759,19 @@ in `command_processor.cc` on `auto/re-ui-draw-order`, and F10 wrote a 2.9 MB
 `xenia_ship_capture_01.log` from this session's binary. No separate
 `capture-ship-placement` build is needed.
 
-What blocks it now is **the cache-flush crash**, not navigation — measured
+**Update 2026-08-19: the mission is now REACHABLE.** With the Canary threading
+fix, `tutorial_launch.sh` drives boot → title → menu → TUTORIAL and the mission
+**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. 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.
+
+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,
 because re-pressing the same title never works) gets all the way from the title
 through the main menu to **DIFFICULTY** and then **SELECT DATA**, and the guest

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

@@ -256,3 +256,57 @@ some runs out earlier — it is not the crash, and it has no diagnosis yet.
 The cheap trigger from the top of this note (an incomplete on-disc cache) still
 stands as the fastest way to reproduce the throw for bisection; what is missing
 is a fix, and that is guest-race work in the emulator, not RE.
+
+
+## The mission is now REACHABLE — and freezes there instead (2026-08-19)
+
+**Status:** ✅ the blocker has **moved**, measured. 🔴 the crash is unchanged and
+still blocks a capture. 🔬 one new lead, deliberately not claimed as a cause.
+
+This entry has said a second capital-ship capture "needs that crash dealt with
+first", because the run died at **SELECT DATA** before any mission existed. That
+is no longer where it stops.
+
+With the Canary threading fix making the menu dependable
+([`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)),
+`tutorial_launch.sh` now drives boot → title → menu → TUTORIAL and **the mission
+loads and renders**: the flight HUD, the "Go to the box on your screen" prompt,
+the warship counters, the controller diagram
+([capture](captures/tutorial-mission-reached-then-crash.png)).
+
+### What still happens
+
+* **13 243 crash dumps, every one at `PC: 0x82307128`** — the same address this
+  page is about. Guest thread 9, `Access Violation: read at 0x000000010000000C`.
+* Preceded by exactly **one** `RtlRaiseException(E06D7363)` / "Guest attempted to
+  throw a C++ exception!", immediately after a `HostPathDevice::ResolvePath()`
+  with **empty arguments** — the cache-flush shape this page documents.
+* The game then **freezes**: two screenshots 6 s apart are identical (RMSE 0), no
+  new dumps accumulate, and the process still burns 400 % CPU. Xenia suspends the
+  crashing thread and the mission stops advancing.
+
+So the honest status is: reachable, renders, unusable for a capture.
+
+### 🔬 A new lead, not a claim
+
+The `XThread::Resume: host resume was refused` diagnostic added with the
+threading fix fires **1 671 times** on this path — and **1 663 of them are the
+same thread, `F80001D8`**, with 152 before the first crash. On the menu path it
+fires about 7 times.
+
+That is *not* asserted to be a bug. Resuming a thread that is not suspended
+legitimately returns false, and "call Resume to kick a worker" is a normal guest
+idiom that would produce exactly this. But 1 663 refusals on one thread,
+concentrated where the crash is, is specific enough to test: check whether
+`F80001D8` makes any kernel calls between refusals. If it does, it is the kick
+idiom; if it does not, it is a second lost resume.
+
+### The cheapest next test is the cache
+
+This page already establishes that an **incomplete on-disc cache** triggers the
+throw and that "with the cache complete, the same boot produces no throw at all".
+The cache directory is currently **40 MB**, and the tree still carries
+`aab216c3.partial-2131` and `aab216c3.cold-rebuilt-2145` from earlier surgery —
+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.