re: build 4 captured without the plate, and keyframe groups hold rather

than loop

The port agent ranked a plate-free capture of build 4 above any further
static RE, so that came first.

B from the main menu returns to the title and the plate fades in a beat
later, which opens a clean window. Recorded at 20 fps from the press: the
art appears at 1.10 s, builds in to 3.70 s, sits settled and unobstructed
until 5.00 s, and the plate arrives at 5.10 s -- the band jumps from 282
to 3755 bright pixels. Committed the frame at 4.0 s as the reference for
the cyan glow slab they report drawing and the game not having.

Their other sub-question -- whether a keyframe group loops or holds --
falls out of the decoded sweeps plus a measurement I already had, and the
two agree. ptloop01's final keyframe parks pteff03.t32 at x=1521 and
ptloop02's parks pteff03a.t32 at x=-839, both off-screen on a 1280-wide
design; and over 18 s of settled title the centre tiles sit at sd <= 0.01
when a looping group would recross the screen every 7.5 s. So groups HOLD
at the last keyframe. The loop*.rat name is misleading.

Also recorded, in the corpus rather than only in their report: the
rest_plateau bug, with their exact identifying condition -- the final
untimed keyframe has the same pose as the last timed one -- the six
elements it misses on main_menu, and the bracket it drops. That closes an
open question ui-paint-order-key.md has carried for a while about
ptframe1 and ptframe2 resting at alpha 0 while the capture shows the
frame plainly. Same two elements, same cause. Not fixed yet; the change
is in ui_layout's rest().

And a METHOD line I would not have written myself: two renderers agreeing
is not evidence the field is right. Their composite and screen render
matched to 3/255 on main_menu and both omitted two elements the game
draws, because both read one field through one decoder.

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

@@ -314,3 +314,40 @@ declared `16 → 261` (4.08 s); the two are not measuring the same thing.
 
 Testing it properly needs the title reached **without** a skip, and a way to
 separate the quad from the elements — neither of which this recording had.
+
+
+## ✅ For the port: build 4 alone, and groups HOLD rather than loop
+
+Both answers the port agent asked for, in one recording.
+
+### The capture — the title with no `PRESS Ⓐ` plate over it
+
+Ⓑ from the main menu returns to the title and the plate fades in **a beat later**,
+which opens a clean window. Recorded at 20 fps from the press:
+
+| | |
+|---|---|
+| title art appears | t ≈ 1.10 s |
+| builds in | 1.10 → 3.70 s (mean 41.8 → 63.2) |
+| **settled, still no plate** | **3.70 → 5.00 s** |
+| plate arrives | t ≈ 5.10 s (band jumps 282 → 3 755 bright px) |
+
+[`live-title-build4-no-plate.png`](captures/title-builds/live-title-build4-no-plate.png)
+is t = 4.0 s — build 4, settled, unobstructed. That is the reference for the
+washed-out cyan glow slab the port reports drawing and the game not having.
+
+### ✅ A keyframe group HOLDS at its last keyframe — it does not loop
+
+This follows from the decoded sweeps plus a measurement, and the two agree:
+
+* `ptloop01.rat`'s final keyframe puts `pteff03.t32` at **x = 1521** and
+  `ptloop02.rat`'s puts `pteff03a.t32` at **x = −839** — both **off-screen** on a
+  1280-wide design. A group that holds therefore parks both sweep sprites out of
+  view and nothing moves after the build-in.
+* Measured: over 18 s of settled title the centre tiles sit at **sd ≤ 0.01**
+  (per-tile map above). A looping group would recross the screen every **7.5 s**
+  and be unmissable.
+
+So the name `loop*.rat` is misleading — in this build the records animate **once**
+during the build-in and then rest off-screen. 🟡 This is about *these* groups on
+*this* screen; nothing here says no group anywhere loops.