re: the splash's timing is decoded, and the fade-out matches to 0.03 s

Closing the caveat I left last iteration -- the splash timing was +/-0.5s
because I sampled at 2 fps, and at that rate I could not see ramps at
all, only plateaus.

Re-recorded at 10 fps: the splash FADES, both in and out, rather than
cutting. And the bundles declare it. palogo_sqex.t32 carries keyframes
[15 30 235 239 251 255] and palogo_gamearts.t32 [15 30 190 194 206 210],
each with an _eff glow child on [15 30 45]. Under Q1's 1 unit = 1/60 s
that is a 0.25 s ramp in, a 3.42 s or 2.67 s hold, and a 0.33 s fade out
-- against measured holds of about 3.5 s and 2.4 s and fade-outs of about
0.3 s. The constant 0.35 s offset between declared and measured start is
just that my recording's t=0 is when the WINDOW appears, not when the
guest starts drawing.

So the first screen's animation moves from measured to decoded: the port
reads it off the disc instead of trusting my stopwatch.

It also explains something the capture showed and I had no account for.
The brightness overshoots on the way in -- peaks at 0.8 s, settles by
1.1 s -- which reads as a bloom. It is the _eff glow child, whose
keyframes run 15 -> 30 -> 45, ramping in after the logo and back down
while the logo holds. Mechanical, not a rendering artifact.

docs/re/ui-title-build-map.md

@@ -101,7 +101,45 @@ Both halves match their own render at zero shift and are firmly rejected by the
 other. The `13`/`14` twins score 0.876 / 0.966 — near-identical artwork, so this
 test cannot tell a pair apart, only a screen from a different screen.
 
-### ✅ And the splash is timed
+### ✅ The splash's timing is DECODED, and the capture confirms it
+
+Re-recorded at **10 fps** (the 2 fps pass below was ±0.5 s and could not see
+ramps at all). The splash **fades, both ways** — it does not cut — and the
+bundle's own keyframes say so:
+
+```
+$ sylpheed-cli screen info --all --build 10 GP_TITLE.pak
+1  palogo_sqex.t32       7 kf  [15  30  235 239 251 255  -]
+2  palogo_sqex_eff.t32   4 kf  [15  30  45  -]              (the glow, child of 1)
+
+$ ... --build 11
+1  palogo_gamearts.t32   7 kf  [15  30  190 194 206 210  -]   (seta, anima identical)
+2  palogo_gamearts_eff   4 kf  [15  30  45  -]
+```
+
+Under Q1's `1 unit = 1/60 s`:
+
+| | declared | measured at 10 fps |
+|---|---|---|
+| `SQUARE ENIX` ramp in | `15 → 30` = 0.25 s | rise 0.4 → 0.8 s |
+| `SQUARE ENIX` hold | `30 → 235` = **3.42 s** | ≈ 3.5 s (0.8 → 4.3 s) |
+| `SQUARE ENIX` fade out | `235 → 255` = **0.33 s** | **≈ 0.3 s** (4.4 → 4.7 s) |
+| developer hold | `30 → 190` = **2.67 s** | ≈ 2.4 s (5.6 → 8.0 s) |
+| developer fade out | `190 → 210` = **0.33 s** | **≈ 0.3 s** (8.1 → 8.4 s) |
+
+The offset between declared and measured start is ≈ 0.35 s, which is simply that
+the recording's `t = 0` is when the *window* appears, not when the guest starts
+drawing. Everything downstream of that lines up.
+
+**The overshoot is the glow.** The measured rise peaks (6.21) at 0.8 s and settles
+back (5.39) by 1.1 s, which looks like a bloom. It is the `_eff` child element:
+its keyframes are `15 → 30 → 45`, so it ramps in *after* the logo and then back
+down, while the logo itself holds. Decoded, not a rendering artifact.
+
+So the port can **read** the splash's timing off the disc rather than author it —
+the first screen's animation is not a measurement it has to trust.
+
+### The wall-clock sequence, for orientation
 
 | | |
 |---|---|