re(ui): answer four of the port's five asks -- splash, fade-out, focus, gamma

1 SPLASH ADDRESSING (was blocking P3). No content predicate exists: design size
fails (every extra composable bundle sampled is 1280x720, like every screen) and
element count fails (fragments run 2..15, the splash halves are 3 and 7). But
GP_TITLE needs none -- `--all` adds exactly four bundles there and all four are
real screens, with the --all index equal to the pak entry index 1:1. And there
are TWO splash screens: 11/14 are the developer logos, 10/13 are the SQUARE ENIX
publisher wordmark, which the port did not have and which the boot shows first.

2 FADE-OUT (was blocking P3). It is (a), and it is bigger than the fade quad.
Every element ends on exactly ONE untimed keyframe, which rules out (b); that
block is where the screen plays out -- quad to a=255, buttons/labels/glows to
a=0, frames hold. (c) is refuted by a null test that discriminates: a black quad
alone holds the button/background brightness ratio constant, and through the
fade it falls 6.50 -> 1.94, 3.4x monotonic.

3 FOCUS (saves P5 rework). Over-vs-instead is unobservable -- the focused sprite
covers the base at 100.0% of base-visible pixels on three pairs once aligned
(true offset (7,7); the centre alignment reads a misleading 78-84%), and
compositing both ways differs by RMSE 1.1 inside the button rect. The real defect
is the focus record's SECOND element: ptbtn0Nf.rat declares ptbtneff01.t32 (a
42x46 glowing ring, focus only) plus the bright label, where the base declares
one sprite. That ring is the marker the port draws nowhere.

5 GAMMA. The capture is not neutral: capture ~ 255*(render/255)^g, g ~ 1.34-1.49,
and the chain says it is a ramp the GAME installed, not a capture artefact. So
RMSE against captures has a floor. Reach stated: the flat patches are all dark
(render ~0-60), so midtones and highlights are unconstrained.

4 ROTATION is a human's call and is recorded in MISSION, not acted on -- the port
rotating while the reference renderer does not would make verify-screen report a
large diff meaning "the port is right". The RE half is answered: rotation is
about the declared pivot, measured against a GPU capture.

The focus record's +20 element-count word is marked 🟡 not ✅ -- read on GP_TITLE's
ten button records only; the disc-wide check is written and still running.

docs/port/MISSION.md

@@ -208,6 +208,28 @@ settled and only multi-keyframe absolute timing is open; `rest()` differs from
 its alternative on **one** element across all five screens, and the current
 answer there is the defensible one.
 
+## 🔵 Needs a human decision — rotation (raised 2026-08-29)
+
+The port agent asks whether it should **render** `rotation_deg` (decoded at
+keyframe `+12`) when `sylpheed-cli screen render` deliberately does not. Its own
+framing is the reason this is not mine to settle: if the port rotates and the
+reference renderer does not, then `verify-screen` reports a large title diff that
+means *"the port is right"* — a silently inverted signal.
+
+The RE half is answered and is in HANDOFF: rotation is about the **declared
+pivot** (measured against a GPU capture, not assumed), and it changes nothing on
+the five screens **at rest**.
+
+What needs a decision is which way the divergence gets closed:
+
+* teach `ui_layout::blit` a rotating path, so the two renderers stay comparable
+  and the diff keeps meaning "someone is wrong" — costs work in the reference
+  renderer, which is otherwise not on the port's critical path; or
+* let the port render rotation and mark the title as a known-divergent screen in
+  `verify-screen`, accepting a check that no longer guards the title.
+
+Recorded rather than chosen, per "do not improvise around a blocker".
+
 ## Known unknowns — say so, do not fill them in
 
 Some of these may turn out to be undecodable. That is a valid, useful answer, and