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