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/structures/ui-resting-pose.md

@@ -153,3 +153,37 @@ invisible — in the literal sense — until `fade` is applied.
   0 and never hold at a visible value, so the plateau rule rests them at alpha 0
   — invisible. That is *probably* right for a settled screen, but the capture
   cannot confirm it while `fade` is unapplied.
+
+
+## 🔴 `rest_plateau` is wrong for elements with no exit animation (2026-08-28)
+
+Reported by the port agent with a capture that proves it, and it affects
+`sylpheed-cli screen render` too — this is not only a port concern.
+
+`rest_plateau` drops a trailing run of identical keyframes because that run is
+normally the **exit** animation. On an element that has **no exit**, the trailing
+run *is* the hold, and dropping it puts the element back at its **first**
+keyframe — off-position and transparent.
+
+**The condition that identifies these exactly** (no false positives across the
+port's whole export):
+
+> the final untimed keyframe has the same pose as the last timed one
+
+**Six elements** on `main_menu` match it and `rest()` misses all six. The
+visible cost: on `main_menu` the timeline render and the `rest` render differ in
+exactly one region — **400 × 470 at (440,108)**, the bounding box of `ptframe1`
+and `ptframe2` and nothing else. That is the **bright circuit bracket around the
+menu**, plainly present in
+[`../captures/main-menu-oracle.png`](../captures/main-menu-oracle.png) and absent
+from the `rest` render. Cropping the same region from the capture and from both
+renders puts the ring and its elbow trace pixel-aligned with the game's in the
+timeline render.
+
+This also explains a long-standing ❔ on
+[`ui-paint-order-key.md`](ui-paint-order-key.md): *"`ptframe1`/`ptframe2` rest at
+`0x00ffffff` (alpha 0) and are therefore not drawn, but the capture shows the menu
+frame plainly."* Same two elements, same cause — now identified.
+
+❔ **Not yet fixed.** The change belongs in `ui_layout`'s `rest()`; it is a
+decoder change and has not been made.