re(ui): the sequencing survives refutation -- and a bundle is a palette

Two checks on last iteration's "sequential, not simultaneous" reading.

First, the phases really are disjoint. If glows and logos ever shared a
frame the claim would be wrong. Across all 235 captured frames the count
of frames containing both is ZERO, and the switch is a single clean
boundary -- f110-115 draw 1280x720 + 262x108 + 525x90, f116 onward
1280x720 + 243x86 + 499x72. Two sprites either side, no transition frame.

Second, and larger: a third of the bundle is never drawn. Entry 11
declares three logo/glow pairs and only two appear.

  palogo_gamearts / _eff    95 / 22 frames
  palogo_seta     / _eff    95 / 22 frames
  palogo_anima    / _eff    never

palogo_anima declares the SAME keyframe times as palogo_gamearts. Two
elements with byte-identical data, 95 frames and 0 frames in one run.
Reach: the capture covers frames 1-214, so this is "never in the window".

So a bundle is a palette, not a script. Its elements say what to draw and
for how long; which of them run, and when each starts, is decided outside
the placement data. That is the same conclusion the boot-order work
reached from the other end -- the driver is code, not data -- now with a
per-element measurement behind it.

For the port, concretely: compositing every element of a bundle does not
reproduce what the game shows over time. It is the right thing for a
static screen that settles, and it is not a timeline.

METHOD: two elements with identical data and different outcomes is the
strongest possible evidence that the decision is elsewhere.

docs/re/METHOD.md

@@ -802,3 +802,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   right, so what is absent is a per-group start — and it pointed straight at the
   one undecoded word in the group header. (Which was zero, but the diagnosis was
   still what made the next step obvious rather than a search.)
+* **Two elements with identical data and different outcomes is the strongest
+  possible evidence that the decision is elsewhere.** `palogo_anima` and
+  `palogo_gamearts` carry byte-identical keyframe times; one is drawn for 95
+  frames and the other not at all. No amount of re-reading the placement data can
+  explain that, and the pair is worth more than a survey — when a hypothesis says
+  "the data decides", look for two records that agree and behave differently.

docs/re/REFUTED.md

@@ -572,3 +572,12 @@ neighbourhood, not just the line.
   origin needs f₀ ≈ 93.5 for `palogo_gamearts_eff` and f₀ ≈ 103 for
   `palogo_gamearts`, ~19 units apart, and aligning one throws the other off by
   ~9 frames at both ends. Durations match (97.8 %, 98.5 %); starts do not.
+* "the glows and logos might overlap and my size-grouping merged them" → **tested
+  and refuted.** Across all 235 captured frames, **zero** contain both a glow and
+  a logo; f110–115 draw two glows and f116 onward two logos, with no transition
+  frame. The sequencing is real.
+* "a bundle's declared elements are what the screen shows" → **refuted.** Entry 11
+  declares three logo/glow pairs and only two are ever drawn — `palogo_anima`
+  gets 0 frames against `palogo_gamearts`'s 95, from byte-identical keyframe
+  times. (Reach: within the capture's frames 1–214.)
+  [`ui-group-start-time.md`](structures/ui-group-start-time.md)

docs/re/structures/ui-group-start-time.md

@@ -60,3 +60,50 @@ on the same screen. On the developer splash the observed order is: both glows
 together, then both logos together. That is a **measured** sequence for one
 screen, not a decoded rule — a port animating a screen has to author the
 sequencing, and should know it is authoring.
+
+---
+
+## ✅ Verified against its own refutation — and it goes further than start times
+
+**2026-08-29.** Two checks on the "sequential, not simultaneous" reading.
+
+### The phases really are disjoint
+
+If the glows and logos ever shared a frame, the sequencing claim would be wrong.
+Across all 235 captured frames, the number of frames containing **both** a glow
+and a logo is **zero**. The switch is a single clean boundary:
+
+```
+f110–115   1280x720 + 262x108 + 525x90     ← both glows
+f116–122   1280x720 + 243x86  + 499x72     ← both logos
+```
+
+Two sprites either side, no overlap, no transition frame.
+
+### A third of the bundle is never drawn at all
+
+Entry 11 declares **three** logo/glow pairs. Only two are ever drawn:
+
+| sprite | declared | drawn |
+|---|---|---|
+| `palogo_gamearts` / `_eff` | 500×71 / 521×91 | **95 / 22 frames** |
+| `palogo_seta` / `_eff` | 240×89 / 261×110 | **95 / 22 frames** |
+| `palogo_anima` / `_eff` | 388×136 / 407×156 | **never** |
+
+…and `palogo_anima` declares the *same* keyframe times as `palogo_gamearts`.
+⚠️ Reach: the capture covers frames 1–214, so this is "never **within the
+window**", not "never". The pair may follow after it.
+
+### What that means for a consumer
+
+**A bundle is a palette, not a script.** Its elements carry what to draw and for
+how long; which of them run, and when each starts, is decided outside the
+placement data — selectively enough that two elements with byte-identical
+keyframe times get 95 frames and 0 frames in the same run.
+
+That is the same conclusion the boot-order work reached from the other end
+(*the driver is code, not data*), now with a per-element measurement behind it.
+
+⚠️ Concretely: **compositing every element of a bundle does not reproduce what
+the game shows over time.** It is the right thing for a static screen that
+settles, and it is not a timeline.