re: the boot harness was blinking slower than the title -- diagnosed

Four consecutive runs failed to reach the interactive title, across two
locales, two launch paths and two display-gamma settings. I attributed it
in turn to a stale oracle, to the locale, and to the attract loop. It was
none of those.

  one `screenshot` call, emulator running:  10.8 s
  one `screenshot` call, emulator killed:    0.117 s

92x, measured at a 1-minute load average of 1.80 -- so it is contention
with the emulator through the X server, not background load.
skip_intro.sh takes two grabs per iteration plus a numpy import, giving a
median sampling interval of 41 s in the last run (38/82/41/20/30/30/35/
47/46/45/44/43/21/19). The title lasts "a few seconds" before the attract
loop reclaims it -- wait_title.sh's own header says so. The harness was
sampling slower than the event it was waiting for. That also explains why
runs at 16:43-18:05 the same day succeeded.

Withdrawn as CAUSES, though the observations stand: "the JP run never
reaches the interactive title", "neither locale reaches it without a pad
press", and "the game sat in the attract loop for 604 s". The English
control did control for locale -- it just shared the same defect.

Also recorded: I set kernel_display_gamma_type = 0 for the gamma control
run, which brightens the frame (mid-attract mean 122.8 vs 52.5/82.8 at
type 2) -- and skip_intro classifies movie-vs-static on an ABSOLUTE rmse
threshold, so the gamma change biased the very classifier the run
depended on. Changing a display setting and a capture behaviour in one
run confounds both. Config restored to type 2.

The fix is not applied: make the probe cheap enough to outpace the title
window (small region, no convert round trip, one long-lived process).
Every remaining emulator-side question is waiting on that.

docs/port/MISSION.md

@@ -114,6 +114,15 @@ independent landmarks rather than guessed:
 `XLanguage::kJapanese = 2` (`xbox.h:307`). Writing 2 there and restoring
 afterwards is using canary's own persistence, not patching its code.
 
+**🔴 DIAGNOSED 2026-08-29 — the harness, not the game.** `screenshot` costs
+**10.8 s while xenia is running** and **0.117 s once it is killed** (92×, at a
+1-minute load average of 1.80, so it is contention with the emulator). A
+two-grab polling loop therefore samples every **~41 s**, against a title screen
+this corpus documents as lasting *a few seconds*. Four runs — two locales, two
+launch paths, two gamma settings — were all blinking slower than the event.
+Everything below is the trail that led there; the conclusions it draws about the
+*game* are withdrawn. See [capture-harness-status](../re/capture-harness-status.md).
+
 **🟡 Still not settled — two runs, and the reason moved again.**
 
 *Run 1 (2026-08-28)* reported "title not seen" in 787 s. **That was a broken