docs: the timeline lands on rest -- except on six elements, where the game

agrees with the timeline

P2's gate is the buttons sliding in, and `tools/screen-strip` renders the strip
that shows it. But the useful result came out of checking where the animation
settles.

On 8 of 12 screens the settled timeline is BYTE-IDENTICAL to the declared `rest`
pose -- the port walks the keyframes with an authored time unit and arrives, to
the pixel, where the pinned decoders independently say the screen rests. On
`main_menu` the two differ in exactly one region, 400x470 at (440,108): the
bounding box of `ptframe1` and `ptframe2` and nothing else.

`rest` puts both at their first keyframe, off-position and transparent. The
capture of the running game shows them -- the bright circuit bracket around the
menu. Cropping the same region from the capture and from both renders puts the
ring and its elbow trace in the timeline render pixel-aligned with the game's,
and absent from the rest render. Geometry, so it does not depend on the
capture's gamma or on its having been taken with NEW GAME focused.

`ui_layout::rest_plateau` excludes a trailing run of identical keyframes because
it is normally the exit. On an element with NO exit animation the trailing run IS
the hold. The condition that identifies these exactly, with no false positives
here, is "the final untimed keyframe has the same pose as the last timed one" --
six elements, and `rest()` misses all six. Filed in BLOCKED.md for the RE agent:
the decoders are pinned and are not this port's to fix, and `sylpheed-cli screen
render` is missing the bracket too.

Worth saying plainly what this does to P1: the port and the reference agreed on
`main_menu` to 3/255 and BOTH were missing two elements the game draws. Two
renderers reading one field through one decoder agreeing is not evidence the
field is right. BLOCKED.md had already said that about the pivot; here it bit.

The title is NOT settled and P2 does not claim it. `rest` and the timeline
disagree there by 142-247/255, the only live title capture composites the PRESS A
plate over build 4 so it cannot be diffed against the title alone, and both of
the port's modes draw a cyan glow slab the game does not have -- a third problem,
P3's. Recorded as an open question rather than resolved by tuning.

Also reconciled against the RE agent's new work: Q8 is answered -- the SE waves
are located in `Static.slb` (move/confirm/back), which unblocks P6's audio; and
the title's transitions are a lookup by NAME, giving P3/P5 the game's own screen
vocabulary as candidate `goto` targets, marked as the name match it is.

docs/FORMAT.md

@@ -187,6 +187,22 @@ keyframes with an identical pose that does not end the group. Neither the first
 nor the last keyframe, and not the longest-dwell frame either: a long gap after
 keyframe *k* means the screen spends that time *arriving at* `k+1`.
 
+> ⚠️ **`rest` is a heuristic over the keyframes, and it misfires.** The rule
+> excludes a run that ends the group, because that run is usually the exit. On
+> an element with **no exit animation** the trailing run *is* the hold, and the
+> rule then falls back to an earlier run — usually the invisible pre-roll. Six
+> elements in this export are affected, and the condition that identifies them
+> exactly is *"the final untimed keyframe has the same pose as the last timed
+> one"*: `ptframe1`/`ptframe2` on both main menus, and `pteff02` on both titles.
+> A live capture of the running main menu shows `ptframe1`/`ptframe2` on screen;
+> `rest` says they are invisible.
+>
+> A consumer that wants the pose after arrival should therefore take **the last
+> timed keyframe**, not `rest`. `rest` is kept in the format because it is what
+> the pinned decoders say and removing it would hide the disagreement — see
+> `docs/DECISIONS.md`. The format is unchanged at **v2**: no field changed
+> meaning, this is a warning about one of them.
+
 **`paint_order`** is back-to-front, as declaration indices, and is a permutation
 of them. It is the stable sort by `layer`. See `unresolved: paint_order_ties`.