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/METHOD.md

@@ -261,3 +261,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   finding landed in `docs/re/` while the page the port agent reads kept the stale
   version. The commit's file count is the tell: if it is one short, an edit was
   silently dropped.
+* **Two renderers agreeing is not evidence the field is right.** The port's
+  composite and `sylpheed-cli screen render` matched on `main_menu` to 3/255 —
+  and *both* omitted two elements the game draws, because both read one field
+  through one decoder. Agreement between consumers of the same decode measures
+  the decode's determinism, not its truth. Only a framebuffer capture is an
+  independent check. (Reported by the port agent, 2026-08-28, after a capture
+  crop found the missing bracket.)