re(ui): withdraw the mechanism -- "palette" was an explanation, not a finding

Last iteration I wrote that a bundle is a palette whose elements are
selectively activated. The disjoint glow/logo phases have two
explanations and I asserted one:

  1. one bundle, some elements run then others;
  2. two bundle-loads shown in sequence (entries 11 and 14 are twins
     declaring identical sprites).

The draw log's tex[base=...] looked like it would separate them. It does
not, and the control is in the same table:

  publisher splash  f1-90     0x11C30000, 0x10000000
  glows             f94-115   0x11C30000, 0x10000000
  logos             f116-211  0x11C30000, 0x10000000

The publisher splash is certainly a DIFFERENT bundle from the developer
splash, and it uses the same base. So 0x11C30000 is a reused upload slot,
not a bundle identity, and the test cannot choose between the two
hypotheses.

Survives: a bundle's declared elements are not what gets drawn.
palogo_anima and palogo_gamearts carry byte-identical keyframe times and
in the same run one is drawn 95 frames and the other none -- and
whichever twin was active declares both. The phases are strictly disjoint
(0 overlapping frames in 235).

Withdrawn: the mechanism. The practical consequence is unchanged --
compositing every element of a bundle does not reproduce what the game
shows over time -- but the why is not established and I stated it as
though it were.

What would separate them: a per-draw capture recording the bundle each
draw came from, or a file-IO log showing whether a second RATC entry is
read between frames 115 and 116.

METHOD: a shared resource address does not identify the resource's owner;
and state the mechanism as a separate claim from the observation, or the
weaker one inherits the stronger one's evidence.

docs/re/METHOD.md

@@ -808,3 +808,14 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   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.
+* **A shared resource address does not identify the resource's owner.** The draw
+  log's `tex[base=…]` looked like it would say whether two animation phases came
+  from the same bundle. All three splash phases report `0x11C30000` — including
+  the publisher splash, which is certainly a *different* bundle. The address is a
+  reused upload slot. The control was free and sitting in the same table; without
+  it the shared base would have read as proof of a shared bundle.
+* **State the mechanism as a separate claim from the observation.** "Declared
+  elements are not what gets drawn" is measured and holds. "Because one bundle
+  activates its elements selectively" was an explanation I attached to it, and it
+  is not established. Bundling the two let the weaker claim inherit the stronger
+  one's evidence.

docs/re/REFUTED.md

@@ -581,3 +581,10 @@ neighbourhood, not just the line.
   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)
+* "the glow and logo phases are one bundle with elements selectively activated"
+  → **mine, and withdrawn as unestablished.** The alternative — two compositions
+  shown in sequence — fits equally. The texture-base test fails its control: the
+  publisher splash is a different bundle and shares the base `0x11C30000`, so
+  that address is a reused upload slot, not a bundle identity. What survives is
+  that declared elements ≠ drawn elements.
+  [`ui-group-start-time.md`](structures/ui-group-start-time.md)

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

@@ -107,3 +107,47 @@ That is the same conclusion the boot-order work reached from the other end
 ⚠️ 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.
+
+---
+
+## 🔴 Narrowing "a bundle is a palette" — the mechanism is NOT established
+
+**2026-08-29.** The glow phase and the logo phase are disjoint, but there are two
+explanations and I asserted one of them:
+
+1. **one bundle, selective activation** — the game runs some of entry 11's
+   elements, then others;
+2. **two bundle-loads in sequence** — the game shows one composition, then
+   another (entries 11 and 14 are twins declaring identical sprites).
+
+The draw log records each draw's **texture base**, which looked like it would
+separate them. It does not:
+
+| phase | frames | texture bases |
+|---|---|---|
+| publisher splash | 1–90 | `0x11C30000`, `0x10000000` |
+| glows | 94–115 | `0x11C30000`, `0x10000000` |
+| logos | 116–211 | `0x11C30000`, `0x10000000` |
+
+**The test fails its own control.** The publisher splash is certainly a different
+bundle from the developer splash — different entry, different artwork — and it
+uses the *same* base. So `0x11C30000` is a reused upload address, not a bundle
+identity, and it cannot distinguish hypothesis 1 from hypothesis 2.
+
+### What survives, and what I withdraw
+
+✅ **Survives:** a bundle's declared elements are not what gets drawn.
+`palogo_anima` and `palogo_gamearts` carry byte-identical keyframe times, and in
+the same run one is drawn for 95 frames and the other for none — whichever of the
+twins was active declares *both*. The phases are also strictly disjoint (0 frames
+of overlap in 235).
+
+🔴 **Withdrawn:** the mechanism. "One bundle, elements activated selectively" was
+my reading, and the evidence does not choose it over "two compositions shown in
+sequence". The practical consequence is the same either way — compositing every
+element of a bundle does not reproduce what the game shows over time — but the
+*why* is not established and should not have been stated as though it were.
+
+❔ What would separate them: a per-draw capture recording the **bundle** each draw
+came from, or a kernel/file-IO log showing whether a second RATC entry is read
+between frames 115 and 116.