09f189bf12
Built upstream/canary_experimental (a5a18f5c7, 82 commits ahead of our merge base) clean, to answer whether the 0x82307128 mission crash is ours or theirs. Two tooling gaps found building it: version.h is never generated (upstream's xenia-build.py writes it, build-canary does not invoke it, and our tree only builds because a stale copy from an old sylpheed-re build sits in the build dir), and build-canary reports exit 0 on a FAILED build - only the missing binary gave it away. Pure upstream cannot be driven at all: --hid=file is ours and there is no uinput here. So the honest baseline is upstream plus those three pad commits. That baseline reproduced the LOST RESUME on its second boot - black screen, guest at 522% CPU, newest host thread at 00:00:00 CPU, zero kernel calls from its handle - and upstream's threading_posix.cc still has the two-lock-scope publish. So pure upstream is not a stable state; it carries a bug we had already fixed. Adding ONLY the threading fix on top - still none of the RE instrumentation - reaches Stage 02 FLIGHT: TIME 05:03.75, wingman Rhino 103, radio dialogue, and REMAINING OB 020 with OB badges on targets. The run ended in a legitimate GAME OVER (the unattended craft was shot down, as autopilot-memory-driven.md warns), not a crash. Crash dumps for the whole run: 0, against 384 on the instrumented branch at the briefing alone. So the mission crash is not upstream's. Whether it is in our 50 commits or fixed among upstream's 82 this run does not separate; that needs a bisect. REMAINING OB is visible and moves (020->019->018->017) but is NOT found. A three-snapshot BE-u32 filter left 0 survivors; a differential across widths gave exactly one candidate, 0xbc22e83c, and it is REFUTED - read live it held 26 while the HUD showed 017. The empty u32 filter is itself informative: the counter is not a plain persistent big-endian word.