re(ui): withdraw the render evidence -- rest()'s dwell fallback is unsound

Last iteration I reported a 13.1% render change in GP_TITLE build 7 as
evidence AGAINST the keyframe-time shift, arguing that language twins
should match in brightness. Withdrawn. Localising the diff to an element
shows it is not about the time association at all.

The element is ptlogo_eff3.t32, a transient bloom:

   46: (98,42)  100%,100% a=0
   61: (108,72)   0%,0%   a=0
  103: (108,72) 200%,200% a=255 r=80
    -: (108,72)   0%,0%   a=0   r=150

No two adjacent poses are equal, so there is no plateau, and rest() falls
through to its longest-dwell fallback. The longest gap is 61->103, during
which the sprite grows from nothing to 200% at full alpha and then
collapses. The rule returns whichever end of that movement the indexing
lands on: the invisible frame as decoded, the 200% peak shifted. An
896x389 sprite at 200% is larger than the screen, which accounts for the
entire 13.1% and the entire 4.9-unit luminance gap. I was comparing a
heuristic against itself.

The defect generalises, and structurally. A dwell gap is time spent
interpolating FROM pose k TO pose k+1; neither pose is held during it
unless the two are equal -- which is a plateau, and the plateau path has
already returned by then. So the fallback is guaranteed to be guessing
every time it is reached, under any reading of the times. Every element
with no two adjacent identical poses has a guessed rest pose, in our
renderer and in anything built from it.

Consequences: the case FOR the shift (26x on the hold:fade-out ratio) is
no longer opposed by render evidence -- 10 of 11 builds byte-identical,
the 11th differing only through this heuristic. It is still not adopted,
now because it flips this element to the visibly wrong answer, so the
shift and a decision about plateau-less elements must land together, and
neither half has a capture to verify against.

Default-mode suite green (122 passed, 0 failed across 3 suites so far).

docs/re/METHOD.md

@@ -380,3 +380,19 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   be to treat one as refuting the other and drop the loser. Name what each
   measurement actually constrains — here *timing* versus *pose selection* — before
   deciding they conflict.
+* **Before believing a render diff refutes a decode, find out which element moved.**
+  I reported a 13 % render change as evidence against a keyframe-time hypothesis,
+  on a brightness argument about language twins. One element accounted for all of
+  it, and that element is a transient flash with **no resting pose** — so the
+  difference was our own `rest()` heuristic guessing, and it would have guessed
+  under either reading. A whole-image statistic (pixels changed, mean luminance,
+  correlation) tells you *that* something moved, never *what*, and an argument
+  built on it can be entirely about your own code. Localise the diff to an
+  element and read its keyframes first.
+* **A fallback that only runs when its precondition fails is not a fallback.**
+  `rest()` picks the longest-dwell keyframe when no plateau exists — but a dwell
+  gap is time spent *moving between* two poses, and the only case where an
+  endpoint is genuinely held is when the two poses are equal, which is exactly
+  the plateau the first path already caught. So the fallback is guaranteed to be
+  guessing every time it is reached. When a heuristic's justification is the same
+  condition that routes around it, it has no justification.