re(ui): replicate the keyframe-time shift -- three elements, two screens

The case for reading +36 as "the time the NEXT pose is reached" rested on
one element's fade-out shape, then on one element's hold duration. Both
splash halves supply more, and they agree.

  element            screen              observed hold  as decoded  shifted
  palogo_gamearts    developer splash        83 f          8 f       80 f
  palogo_seta        developer splash        83 f          6 f       80 f
  palogo_sqex        publisher splash       >=77 f *       6 f      102 f

  * the capture opens mid-hold at frame 1, so 77 is a floor.

The readings predict opposite structures. For palogo_gamearts, as decoded:
hold 8f, in 80f, hold 2f, out 6f, out 2f -- an eighty-frame FADE-IN and a
two-frame hold. Shifted: in 8f, hold 80f, out 2f, out 6f, out 2f. The
capture shows an 83-frame hold and no fade-in at all.

The elements that cannot discriminate are not contradicted:
palogo_gamearts_eff observed in 7f / hold 7f / out 8f, and both readings
give 8f phases -- with four blocks the shift only relabels which phase is
which. So the glows, which is where Q1's linear law was measured, say
nothing either way rather than arguing against.

The decoder's default is still unchanged, and the reason is now
articulated rather than assumed. The single thing opposing the shift is
rest() on ptlogo_eff3, where the shifted reading makes the longest-dwell
fallback return the bloom's 200% peak. That fallback is unsound whenever
it runs -- it returns an endpoint of a movement, neither of which is held
-- and checked: the shift does not fix it either. So the objection was
never evidence about the times. Timing had three discriminating
measurements; pose selection had a heuristic guessing.

For the port: animation timing should use the shift; static composites are
unaffected and the five screens' correlations stand. Classified measured,
not decoded -- three elements in one screen family, not a disc-wide check.

docs/re/REFUTED.md

@@ -522,3 +522,9 @@ neighbourhood, not just the line.
   ~45–60 minutes. The 3 h 26 m observed was that work at a load average of 9–14,
   inflated by my own two duplicate runs.
   [`test-suite-runtime.md`](test-suite-runtime.md)
+* "the case for the keyframe-time shift rests on a single element" → **no longer
+  true.** Three elements across two screens discriminate and all favour it:
+  `palogo_gamearts` and `palogo_seta` hold full alpha 83 frames, `palogo_sqex`
+  ≥77, against 6–8 predicted by the current reading and 80–102 by the shifted
+  one. The `_eff` glows fit both and argue against neither.
+  [`ui-keyframe-time-unit.md`](ui-keyframe-time-unit.md)