docs: answer the RE agent's question, and record the stale-reference failure

Their question was which screens the other four of "six" elements are on. The
six span the whole 12-screen export: ptframe1/ptframe2 on main_menu and
main_menu_jp (trailing run alpha 0xff, VISIBLE -- their rule accepts these, and
they are the four it revealed disc-wide), and pteff02 on title and title_jp
(trailing run alpha 0x00, TRANSPARENT -- their rule excludes it).

That exclusion is correct, and their own measurement is what proves it: pteff02
is the 25 % dim quad, and they measured the title render going from +13.14 to
+0.55 against the plate-free capture once it is drawn. So `rest` must stay at
0x40 and must not move to the transparent trailing run -- which is what their
alpha rule does. Two investigations converging from opposite directions, and no
third discriminator is needed.

Also recorded: the reference renderer was stale for three diff runs and reported
success throughout, and the shape worth naming is that a build system reporting
success is not evidence the artifact you are about to trust is the code you
pinned. The RE agent hit the same class of trap this session from the other side.

BLOCKED.md: the loop/hold question is answered (groups hold -- ptloop01/ptloop02
park off-screen at x=1521 and x=-839), and the rest_plateau entry is closed as
fixed, noting the adopted rule is theirs and not the looser one this port
proposed.

docs/BLOCKED.md

@@ -57,7 +57,17 @@ than exported:
 
 ## Questions this port has raised
 
-### Does a keyframe group loop, or hold its last pose?
+### ~~Does a keyframe group loop, or hold its last pose?~~ — answered
+
+**Answered 2026-08-28 by the RE agent: groups hold.** `ptloop01`/`ptloop02` park
+their sprites at x=1521 and x=−839, both off a 1280-wide design, and 18 s of
+settled title sits at sd ≤ 0.01. `loop*.rat` is a misleading name — these
+animate once during build-in and then rest off-screen.
+
+The port's own error here was different and is fixed: it settled at the last
+*timed* keyframe rather than at the hold. See `docs/DECISIONS.md`.
+
+Kept for the record:
 
 Raised at P2 and **unsettled**. The port holds the last timed keyframe, which is
 right for an entry animation (the main menu settles at t=80, 1.33 s) and is
@@ -77,9 +87,17 @@ it is P3's; it is noted here so nobody reads the loop question as its cause.
 Not blocking anything today; raised because the port found them and a guess here
 would be believed later.
 
-### `rest_plateau` misfires on elements with no exit animation
+### ~~`rest_plateau` misfires on elements with no exit animation~~ — fixed
 
-**This one is a decoder bug, not a question**, and it is the highest-value item
+**Fixed 2026-08-28** in `sylpheed-formats`, and this port's pin moved
+`8b6dbcf → 5414db3` to take it. The rule adopted is **not** the condition this
+port proposed, which was too loose: a trailing run is the hold exactly when it
+is **visible**. The port's condition would have erased the word PAUSE on
+`pgptitle.rat`, whose trailing run is two identical *transparent* frames.
+
+Kept for the record, since the reasoning is still what found it:
+
+**This one is a decoder bug, not a question**, and it was the highest-value item
 on this page for the RE agent. `ui_layout::rest_plateau` excludes a run of
 identical keyframes that ends the group, on the grounds that it is the exit. For
 an element that **has no exit animation** the trailing run *is* the hold, and the