re(ui): deliver the measured splash sequence the port has to author

The activation decision is code, and MISSION already says the port
authors the sequence -- so the useful move is to hand over the sequence
measured rather than chase the code. From the 235-frame draw capture, at
1 frame = 1/30 s (2 units/frame, 1 unit = 1/60 s, both settled in Q1):

  publisher: SQUARE ENIX logo    f1-90     90 frames   3.00 s+   at 0.00
  (gap, nothing drawn)           f91-93     3 frames   0.10 s    at 3.00
  developer: both glows          f94-115   22 frames   0.73 s    at 3.10
  developer: both logos          f116-211  96 frames   3.20 s    at 3.83

Three limits, stated with the numbers rather than after them. The capture
opens with palogo_sqex already at a=255, so the publisher phase began
before the window and 3.00 s is a FLOOR -- every "starts at" is relative
to the capture, not to boot. palogo_anima and palogo_anima_eff get 0
draws in all 214 frames, so a third pair's phase is not in this
measurement. And it is one capture, one run: the glow->logo switch being
a single frame boundary with no overlap is a strong shape, but each
duration is one sample.

What is solid is the part that matters: the 0.73 s and 3.20 s phases are
each within 2% of their element's declared span, so the durations are the
bundle's own and only the ordering is authored. That is the difference
between a port transcribing timing and inventing it.

docs/re/data/splash-phase-timeline.txt

@@ -0,0 +1,11 @@
+# Measured splash phase timeline -- from docs/re/captures/ui-timing/splash-build-draws.log
+# 2026-08-29. Frames are VdSwap counts; 1 frame = 1/30 s (2 units/frame, 1 unit = 1/60 s).
+#
+# phase                          frames     n   seconds   start (rel. capture)
+  publisher: SQUARE ENIX logo      1-90    90      3.00+      0.00   <- floor: already at a=255 on f1
+  (gap, nothing drawn)            91-93     3      0.10       3.00
+  developer: both glows          94-115    22      0.73       3.10
+  developer: both logos         116-211    96      3.20       3.83
+#
+# palogo_anima / palogo_anima_eff: 0 draws in the whole 214-frame window.
+# The glow->logo switch is a single frame boundary (f115 -> f116), no overlap.

docs/re/structures/ui-group-start-time.md

@@ -179,3 +179,34 @@ matters.
 eliminating the alternative rather than by assuming it away. The route that
 worked was not a better capture but asking what the competing hypothesis would
 *require on the disc*, and finding it absent.
+
+---
+
+## ✅ The measured splash sequence — what a port has to author
+
+Since the sequencing is not in the placement data, here is the measurement, so a
+port authors from evidence rather than from taste. Frames are VdSwap counts;
+**1 frame = 1/30 s** (2 units/frame × 1 unit = 1/60 s, both settled in
+[Q1](../ui-keyframe-time-unit.md)). Data:
+[`data/splash-phase-timeline.txt`](../data/splash-phase-timeline.txt).
+
+| phase | frames | n | seconds | starts at |
+|---|---|---|---|---|
+| publisher — `palogo_sqex` | 1–90 | 90 | **3.00+** | 0.00 |
+| *(gap — nothing drawn)* | 91–93 | 3 | 0.10 | 3.00 |
+| developer — **both glows** | 94–115 | 22 | **0.73** | 3.10 |
+| developer — **both logos** | 116–211 | 96 | **3.20** | 3.83 |
+
+⚠️ **Three limits on these numbers.**
+
+* The capture opens at frame 1 with `palogo_sqex` **already at `a=255`**, so the
+  publisher phase began before the window. **3.00 s is a floor**, and every
+  "starts at" is relative to the capture, not to boot.
+* `palogo_anima` and `palogo_anima_eff` get **0 draws** in all 214 frames, so the
+  third logo pair's phase — if there is one — is not in this measurement.
+* One capture, one run. The glow→logo switch is a single frame boundary with no
+  overlap, which is a strong shape, but the *durations* are one sample each.
+
+✅ What is solid: the **0.73 s glow phase** and the **3.20 s logo phase** are
+each within 2 % of their element's declared span, so the durations are the
+bundle's own and only the sequencing is authored.