9b17506c1f
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.