re(ui): the rest fallback fires on 2 elements, and "last keyframe" wins there

Scored candidate rest-pose rules by rendering and correlating instead of
arguing, and both results correct something I had published.

First, the exposure. The guessing fallback is reached only by an element
that is plateau-less AND multi-keyframe -- a single-keyframe element
short-circuits at `match len { 1 => first }`. Per screen:

  title (4)               24 elements   2 plateau-less   0 reach the fallback
  main menu (5)           16            5                0
  EXTRAS (6)              18            5                0
  publisher splash (10)    3            2                1
  developer splash (11)    7            2                1

So on the three screens the port cares most about, rest() never guesses.
That is why three different rules render builds 4/5/6 to identical
correlations -- the code is unreachable there, which I nearly read as
"the choice does not matter".

Second, where it does fire, the last keyframe is markedly better:

  publisher splash   dwell +0.9600   last +0.9982   maxalpha +0.9600
  developer splash   dwell +0.9643   last +0.9758   maxalpha +0.9643

That refutes my own earlier refutation. I had killed the last-keyframe
rule by arguing it makes palogo_anima_eff invisible while its two
siblings stay lit, which looked like an artefact. The capture says
otherwise: making it invisible is what improves the match. The sibling
symmetry was my expectation, not evidence.

Caveat kept in front: both captures are single frames of a transient
animation, so this fixes which pose matches THOSE frames, not which is
canonically at rest. Default unchanged -- better on both screens where it
fires and identical on the other three, but it would move 2 305 elements
disc-wide on two measurements. Reachable via SYLPHEED_REST_RULE=last.

Also confirmed: all 195 zero-scale rest poses are inside the corrected
2 305 ambiguous population; none is a single-keyframe element.

METHOD: score a rule where it can differ, or you measure nothing; and an
argument from symmetry is a prediction, not a refutation.

docs/re/METHOD.md

@@ -762,3 +762,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   It died the moment the rule was used to change a rendering, because the result
   was visibly worse. If a measurement implies an action, take the action on
   something you can score.
+* **Score a rule where it can actually differ, or you will measure nothing.**
+  Three rest-pose rules rendered builds 4, 5 and 6 to *identical* correlations —
+  not because they agree, but because the code they change is unreachable on
+  those screens. The signal was on the two splashes, the only builds whose
+  elements reach the fallback at all. Identical results across variants is a
+  clue that the variant is not being exercised, not evidence that the choice does
+  not matter.
+* **An argument from symmetry is a prediction, not a refutation.** I killed the
+  last-keyframe rule because it treats one of three sibling glows differently,
+  which felt like an artefact. Measured, it is the better rule on both screens
+  where it applies. Aesthetic expectations about how authored data "should" look
+  are worth stating as hypotheses and worth nothing as verdicts.