re(ui): answer four of the port's five asks -- splash, fade-out, focus, gamma

1 SPLASH ADDRESSING (was blocking P3). No content predicate exists: design size
fails (every extra composable bundle sampled is 1280x720, like every screen) and
element count fails (fragments run 2..15, the splash halves are 3 and 7). But
GP_TITLE needs none -- `--all` adds exactly four bundles there and all four are
real screens, with the --all index equal to the pak entry index 1:1. And there
are TWO splash screens: 11/14 are the developer logos, 10/13 are the SQUARE ENIX
publisher wordmark, which the port did not have and which the boot shows first.

2 FADE-OUT (was blocking P3). It is (a), and it is bigger than the fade quad.
Every element ends on exactly ONE untimed keyframe, which rules out (b); that
block is where the screen plays out -- quad to a=255, buttons/labels/glows to
a=0, frames hold. (c) is refuted by a null test that discriminates: a black quad
alone holds the button/background brightness ratio constant, and through the
fade it falls 6.50 -> 1.94, 3.4x monotonic.

3 FOCUS (saves P5 rework). Over-vs-instead is unobservable -- the focused sprite
covers the base at 100.0% of base-visible pixels on three pairs once aligned
(true offset (7,7); the centre alignment reads a misleading 78-84%), and
compositing both ways differs by RMSE 1.1 inside the button rect. The real defect
is the focus record's SECOND element: ptbtn0Nf.rat declares ptbtneff01.t32 (a
42x46 glowing ring, focus only) plus the bright label, where the base declares
one sprite. That ring is the marker the port draws nowhere.

5 GAMMA. The capture is not neutral: capture ~ 255*(render/255)^g, g ~ 1.34-1.49,
and the chain says it is a ramp the GAME installed, not a capture artefact. So
RMSE against captures has a floor. Reach stated: the flat patches are all dark
(render ~0-60), so midtones and highlights are unconstrained.

4 ROTATION is a human's call and is recorded in MISSION, not acted on -- the port
rotating while the reference renderer does not would make verify-screen report a
large diff meaning "the port is right". The RE half is answered: rotation is
about the declared pivot, measured against a GPU capture.

The focus record's +20 element-count word is marked 🟡 not ✅ -- read on GP_TITLE's
ten button records only; the disc-wide check is written and still running.

docs/re/screen-transitions.md

@@ -115,3 +115,56 @@ screen's build-in is a separate, longer thing.
   quad);
 * the ~0.4 s fade-out and the black hold are **authored from this page** — the
   disc does not carry them.
+
+## ✅ Which quantity the ~0.4 s is — measured 2026-08-29
+
+Asked by the port: is 0.4 s **(a)** the ramp from the hold to the exit pose, i.e.
+exactly the missing duration of that untimed keyframe, **(b)** several keyframes'
+worth, or **(c)** something the game does independently of the group?
+
+**It is (a)** — and it is bigger than the fade quad. Two facts.
+
+**1. There is exactly one untimed keyframe, and every element has it.** Reading
+`screen info --build 5 --geometry` for the main menu, all 16 elements end on a
+single timeless block; none has two. So there is one unknown duration per screen,
+not a chain of them — which rules out (b) outright. And that final block is not
+idle: it is where the screen *plays out*.
+
+| elements | final untimed block | what it does |
+|---|---|---|
+| `pteff00.prm` (the fade quad) | `a = 255` | goes **black** |
+| `pteff10`, `pteff12`, `ptbtn01…05`, `ptmsg` | `a = 0` | **fade out** |
+| `ptframe1`, `ptframe2` | `a = 255` | hold, and get covered |
+| `ptbase`, `pteff05`, `ptloop*`, `pteff02.prm` | single keyframe | hold |
+
+**2. The capture shows the content fading, not just a black quad arriving.** This
+has a null hypothesis that discriminates: under (c) — the game blackens the frame
+independently — every region is scaled by the same `1 − α`, so the **ratio**
+between a button region and a background region is *constant* through the
+fade-out. Under (a) it must fall, because the buttons ramp to `a = 0` while the
+background elements hold at 255 and are only dimmed.
+
+Measured on [`transition-filmstrip.png`](captures/transitions/transition-filmstrip.png),
+button column ÷ upper-right background art, frame by frame through the fade-out:
+
+```
+frame     0      1      2      3      4      5
+ratio  6.495  5.574  3.105  2.125  1.935   (black)
+```
+
+**A 3.4× monotonic fall.** Constant is refuted. The buttons really are fading
+independently of the overall dim, exactly as their declared final block says.
+(The incoming screen runs it in reverse, 2.22 → 3.47 over frames 7–12.)
+
+⚠️ **Reach.** The filmstrip is downsampled and the "button" region unavoidably
+contains some background, so the ratio is a direction, not a clean alpha
+measurement. It refutes the constant-ratio null decisively; it does not by itself
+pin the 0.4 s to ±0.05 s. And it is measured on **one** transition pair.
+
+### For the port
+
+Write **one** authored constant — the duration of the final untimed keyframe,
+~0.4 s / ~24 units — and **play the group to its end on every element**. Do not
+model the exit as a black rectangle fading over a frozen screen: the buttons and
+labels ramp to transparent at the same time, and that difference is visible.
+