tools+docs: a crash-free mission run, a capture that caught no geometry, and a correction

ship_capture_window.sh polls for the flight screen and presses F10 the moment it
appears rather than after a fixed sleep. One run gave three results.

First, the mission ran with ZERO crashes through t+152s - the first clean mission
run, where the three before it ended at 13243 / 11898 / 11497 - and it renders
and plays: player ship, starfield, full HUD, no dialog.

Second, the capture armed and wrote its file, so the mechanism works in-mission.

Third, and against expectation, the file holds NO ship geometry. 329KB, 181
deduped draws: 180 of them share a single vertex shader, all stride=28 vcount=3
prim=8 at full-screen coordinates, plus one full-screen quad, and not one draw
has positions outside the 1280x720 rectangle. The budget is not the limit -
kShipCaptureBudget is 8000 and only 181 distinct (vbase, WVP) pairs were seen -
and the scene was definitely drawing. The known-good capture from an earlier
session is 2.9 MB.

Fourth, a correction to the previous commit. It said the cache is "REFUTED as the
cure". Too strong: this run used the IDENTICAL complete cache as tut4 and
produced 0 crashes against tut4's 11497. What four runs support is that a
complete cache is not SUFFICIENT to prevent the storm and that run-to-run
variance dominates a 3-run comparison - not that the cache does nothing.

Next step is static: compare this capture's shape against the known-good one to
find why the 3D draws never reach CaptureShipDrawForRE.

docs/re/BACKLOG.md

@@ -769,7 +769,15 @@ missing entry `\aab216c3\6` was real and got written, and the run with a complet
 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
+capture needs `F10` armed *inside* that window. ✅ **Done, and the mission ran
+with ZERO crashes** — first clean mission run, fully rendered. 🔴 **But the
+capture contains no ship geometry**: 181 deduped draws, 180 sharing one vertex
+shader, all screen-space, none 3D — against a known-good 2.9 MB capture from an
+earlier session. The 8 000-draw budget was not the limit and the scene *was*
+rendering. ⚠️ The "cache refuted" claim above is **overstated**: this run used
+the same complete cache as `tut4` and got 0 crashes vs 11 497, so variance
+dominates. **Next (static, no emulator):** compare this capture's shape against
+the known-good one to find why the 3D draws never reach `CaptureShipDrawForRE`. 🔴 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