re: the PRESS-A plate arrives 2.13 s after the title settles, measured twice

The one number the port said decides a structural question on its side: whether
`ScreenView` has to draw two builds at once. It does. The boot title shows
build 4 alone, and 2.13 s after build 4 stops animating it composites build 2
over it. Two independent boots agree to 6 ms (2.138 / 2.132), which is under one
sample interval.

Measure from SETTLED, not from first pixels. "First drawn -> plate" is 3.78 s in
one run and 4.26 s in the other, because the build-in animation itself ran 1.64 s
and 2.13 s -- that spread is the emulator's frame pacing, and it is exactly the
kind of number that looks like a measurement.

Ruled out before believing it: that the plate was pulsing all along, too dim for
a thresholded glyph counter. The counter reads EXACTLY 154 -- the committed
no-plate title's own value -- for every frame of a plateau nearly one full pulse
period long, with zero variation, and the surface mean is flat to +/-0.03 across
it. A cycling overlay moves both.

Also settled, and also not:

  * the black hold between two screens is 0.14-0.30 s, which brackets the port's
    authored 0.17-0.23 s and the file's declared 12 units. Their constant stands.
  * the (A)->menu latency is STILL not available, and now the reason is known.
    Both runs freeze one frame for ~1.4 s at surface mean 26.626 -- agreeing
    between runs to six decimals, and reproduced in run 2 with stream restarts
    disabled, so it is not the capture path. It is a guest load stall: the (B)
    path, which loads nothing, has no freeze at all. Any figure from it would be
    an emulator load time.

Refutation attempt, recorded whether or not it survived: navigation.md's "the
title is not input-ready for about ten seconds, and even then (A) registers
roughly half the time". At 7.29 s and 7.28 s after the title settled, (A) was
accepted first press in both runs, as was (B) on the menu. n=2 only makes "half
the time" unlikely (p ~ 0.25); it contradicts the ten seconds outright.

And the standing red banner is withdrawn: the interactive title IS reachable in
this container, twice, with no pad input, in ~3.5 minutes. Why it changed is NOT
established -- this container came up with no Xenia storage root at all, so run 1
created a profile -- and that is written as a correlation for the next session to
test rather than as a cause.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw

docs/game/navigation.md

@@ -32,7 +32,7 @@ Confidence: ✅ seen in a capture · 🟡 inferred · ❔ unknown.
 | 1 | **SQUARE ENIX** in white on black, the two dots in red, `™` after it ✅ | nothing | fades on to the next logo |
 | 2 | **GAME ARTS**, **SETA** and **studio anima** stacked on black ✅ | nothing | fades on into the cinematic |
 | 3 | The opening cinematic | **Ⓐ** skips it ✅ | ends into the title |
-| 4 | **Title screen** — the wordmark appears **first, with no prompt**; `PRESS Ⓐ BUTTON` fades in a beat later, above the 2006/2007 Square Enix copyright line ✅ | press **Ⓐ** | goes to the main menu ✅ |
+| 4 | **Title screen** — the wordmark appears **first, with no prompt**; `PRESS Ⓐ BUTTON` fades in **2.13 s** later, above the 2006/2007 Square Enix copyright line, and then pulses about every 2.2 s ✅ | press **Ⓐ** | goes to the main menu ✅ |
 | 5 | **Main menu** | — | see §2 |
 
 Both logo screens are **still pictures the game draws**, not video — neither is a
@@ -54,6 +54,21 @@ boot.
 ⚠️ **The title is not input-ready for about ten seconds** after it appears ✅.
 And even then Ⓐ registers roughly half the time, with nothing yet found that
 predicts which ✅ — budget retries.
+🔴 **Refutation attempt, 2026-08-29 — both halves of that came out wrong on the
+runs I could test.** Two boots, Ⓐ pressed **7.29 s** and **7.28 s** after the
+title art settled (5.15 s and 5.15 s after the prompt appeared): **accepted both
+times, first press, no retry**, and each went straight on to the main menu. Ⓑ on
+the menu was then also accepted first press, both runs.
+⚠️ Reach: **n = 2**, so "half the time" is only made unlikely (2/2 has p ≈ 0.25
+under it), not excluded — but *"not input-ready for about ten seconds"* is
+contradicted outright, because 7.3 s worked twice. Keep the retry budget; drop
+the ten-second wait. Evidence:
+[run 1](../re/data/plate-timing-run1.tsv) · [run 2](../re/data/plate-timing-run2.tsv) ·
+[`title-plate-delay-measured.md`](../re/title-plate-delay-measured.md).
+
+⚠️ **The prompt takes 2.13 s to arrive, measured twice (2.138 s / 2.132 s).**
+Timed from the moment the wordmark stops animating, not from the moment it first
+appears — the build-in itself varies by half a second between runs.
 
 ---