re(ui): the keyframe-time shift is favoured 26x by timing, rejected by a render

Follow-up on last iteration's unadopted candidate (+36 holds the NEXT
pose's time, not its own). Two new results, pointing opposite ways, and
both are reported.

FOR, and calibration-free: the observed full-alpha hold : fade-out ratio
on palogo_gamearts is 83 : 13 frames = 6.38. The shifted reading predicts
8.00. The current reading predicts 0.25 -- off by 26x. With the glow's 2
units/frame fixed and nothing else free, the current reading says the
logo holds full alpha for 2.0 frames; the capture holds it for 83. This
is no longer the shape argument the candidate rested on.

Also for: rest()'s plain max-dwell fallback picks a=0 -- a transparent
pose, for a publisher logo -- under the current reading, and the visible
a=255 hold under the shift. Only the rest_plateau special case rescues
the render today, and that is the case the port agent reported a bug in.

AGAINST: rendering every build of six UI paks under both readings, 10 of
11 compared are byte-identical and one changes -- GP_TITLE build 7, the
Japanese twin of build 4, by 13.1% of pixels. Build 4, the one verified
against a live capture, is unchanged either way, so the single build the
shift moves is the one with no capture to adjudicate it. The proxy goes
against the shift: language twins are the same artwork, and build 7 reads
70.94 mean luminance as decoded against build 4's 71.41, but 76.32
shifted. Correlation does not separate them (0.6206 vs 0.6201).

These constrain different things -- timing versus pose selection -- and
rest() is a heuristic layered on the times, so moving the times moves its
tie-breaks. Adopting the shift means revisiting that heuristic in the
same change, with no build-7 capture to verify against.

Default UNCHANGED. Experiment reachable via SYLPHEED_KF_TIME_SHIFT=1.
Shifted-mode suite: 122 passed, 0 failed across 3 suites at commit time.

docs/port/HANDOFF.md

@@ -258,12 +258,26 @@ authored version can be deleted.
   drawn at all (and that is not culling — the same element is submitted down to
   `a=7` on the way out). Its declared fade-out also spends 12 of 16 units
   dropping only 23/255 of the alpha; the capture shows no such plateau.
-  A candidate — that `+36` holds the *next* keyframe's time — fixes the shape
-  (RMS 4.05 vs 12.13 on two elements) and removes the decoder's "last block's
-  time is unreadable" special case, but does **not** explain the missing fade-in
-  or the lateness, and the `_eff` elements cannot discriminate between the two
-  readings. **Not adopted; the decoder is unchanged.** Take the interpolation law
-  as settled and treat a multi-keyframe group's absolute timing as unverified.
+  🔵 **Followed up, and the candidate is now strongly favoured — but not
+  adopted.** That `+36` holds the *next* pose's time is supported by a
+  calibration-free measurement: the observed full-alpha **hold : fade-out** ratio
+  is 83 : 13 frames = **6.38**, the shifted reading predicts **8.00**, and the
+  current reading predicts **0.25** — off by **26×**. With the glow's 2
+  units/frame fixed and nothing else free, the current reading says the logo
+  holds full alpha for **2.0 frames**; the game holds it for **83**. The shift
+  also makes `rest()`'s plain dwell rule pick the visible hold instead of a
+  fully transparent pose, and removes the decoder's "last block's time is
+  unreadable" special case.
+  🔴 **What stops it:** rendering every build of six UI paks under both readings,
+  10 of 11 are byte-identical and one changes — `GP_TITLE` build 7, the Japanese
+  twin of build 4, by 13.1 % of pixels. Build 4 (the one with a live capture) is
+  unchanged, so the only build the shift moves is the one with no capture to
+  judge it, and the proxy goes against: twins should match in brightness, and
+  build 7 is 70.94 as decoded against build 4's 71.41, but 76.32 shifted.
+  **Default unchanged**, experiment reachable via `SYLPHEED_KF_TIME_SHIFT=1`.
+  **What this means for you:** the interpolation *law* is settled (linear, 2
+  units/frame); a multi-keyframe group's *timing* is not — do not expect a
+  2-frame hold where the game holds 83.
   ✅ **The seconds conversion is settled: `1 unit = 1/60 s`, a 30 Hz title.** The
   re-test this page used to name has been run — 300 submitted frames timed on the
   **idle** title (nothing loading) came out at **28.8 and 28.3 fps**, the same