re(ui): kill two candidate meanings for the T8aD 0x02 bit, and fix attribution

The bit at +0x04 was recorded as a real field with its meaning "not
diagnosed", noting ptlogo_back2eff is 0x8830 "despite its name". That note
rested on a size match -- and its size is ambiguous, which is the trap
this corpus already records.

First, a sound attribution. T8aD headers appear in the bundle in RATC
CHILD ORDER, verified on GP_TITLE build 4 against an independent property
-- each header's decoded dimensions versus the dimensions the named child
should have: 18 of 18 match, 0 mismatches. Two of those eighteen share a
size (ptlogo_back2eff and ptlogo_back2eff5, both 1133x280), so a size-keyed
lookup cannot separate them; ordering can. Index 12 is back2eff5 (0x8832,
bit set), index 14 is back2eff (0x8830, bit clear). The documented
counterexample is real and correctly attributed -- now on evidence.

Two candidate meanings tested and refuted:

  bit <=> name contains "eff"        REFUTED: ptlogo_back2eff is an eff
                                     name with the bit clear. All 10
                                     bit-set sprites are eff names, so
                                     the implication holds one way only.
  bit <=> the element is transient   REFUTED: pteff03/pteff03a carry the
                                     bit and run to t=250, ramping to
                                     a=255 and holding.

Up close, the exception pair differs in two header words: +0x04
0x8832/0x8830 and +0x08 0x8083/0x8081 -- layer keys 32899 and 32897. They
are NOT duplicates: their alpha summaries agree to one decimal (4.5%
opaque, 86.7% clear, mean 19.3) but a pixel compare gives max abs diff 21.
Two renditions of one image at one size, which is why the summaries were
not trusted.

Still not diagnosed, and said so -- but the search space is two smaller
and the attribution beneath it is now sound.

METHOD: T8aD headers sit in child order, use that not the size; and
identical summary statistics are not identical data.

docs/re/METHOD.md

@@ -675,3 +675,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   0 occurrences in the release binary, **1** in the debug binary. The debug build
   is the control that proves the test can find the string when it is there —
   without it, "0 occurrences" is just as consistent with a bad grep.
+* **`T8aD` headers sit in RATC child order — use that, not the size, to name
+  one.** Attributing a sprite header to a sprite name by matching decoded
+  dimensions fails whenever two sprites share a size, and `GP_TITLE` build 4 has
+  such a pair (`ptlogo_back2eff` / `ptlogo_back2eff5`, both 1133×280) that differ
+  in exactly the flag being studied. Header order matches child order — verified
+  18/18 on that build against the dimensions as an independent check — so
+  ordering resolves what size cannot.
+* **Identical summary statistics are not identical data.** Two same-sized sprites
+  reported the same %opaque, %clear and mean alpha to one decimal, which reads as
+  "the bundle stores this texture twice". Pixel-comparing them gives max abs diff
+  **21**: two different renditions of one image. Three matching summaries over
+  300 000 pixels is weak evidence of identity; the comparison costs one line.

docs/re/REFUTED.md

@@ -496,3 +496,12 @@ neighbourhood, not just the line.
   `_stream.xtr` appears **once** in the Debug binary and **zero** times in the
   Release binary `run-canary` actually uses.
   [`capture-harness-status.md`](capture-harness-status.md)
+* "the `T8aD` `+0x04` bit `0x02` means the sprite's name contains `eff`" →
+  **refuted, now on evidence.** `ptlogo_back2eff` is an `eff` name with the bit
+  clear; the attribution is confirmed by header-order pairing (18/18 on build 4)
+  rather than by a size match, which cannot separate it from the same-sized
+  `ptlogo_back2eff5`. All 10 bit-set sprites *are* `eff` names, so the
+  implication runs one way only.
+* "the bit `0x02` marks a transient element" → **refuted.** `pteff03` and
+  `pteff03a` carry the bit and run to `t=250`, ramping to `a=255` and holding.
+  [`ui-paint-order-key.md`](structures/ui-paint-order-key.md)

docs/re/structures/ui-paint-order-key.md

@@ -496,3 +496,56 @@ carries the word as `flags`, documented and *not* acted on.
 Worth noting `ptlogo_back2eff` carries `0x8830` **despite** having `eff` in its
 name — so the split is the field's, not a naming pattern's. What the bit *does*
 mean is still unknown.
+
+---
+
+## 🟡 The `+0x04` bit `0x02`: two candidate meanings killed, attribution now sound
+
+**2026-08-29.** This page recorded the bit as a real independent field
+(set in 27.1 % of 19 216 sprites) with its "additive blend" reading refuted and
+its meaning ❔ *not diagnosed*, noting that `ptlogo_back2eff` is `0x8830`
+"despite its name". Two things here: that note rested on a **size match**, and
+the size is ambiguous.
+
+### ✅ First, a sound way to attribute a header to a name
+
+`T8aD` headers appear in the bundle **in RATC child order**. Verified on
+`GP_TITLE` build 4 by an independent property — each header's decoded
+dimensions against the dimensions the named child should have:
+
+**18 of 18 match, 0 mismatches.**
+
+That matters because two of the eighteen share a size (`ptlogo_back2eff` and
+`ptlogo_back2eff5`, both 1133×280), so a size-keyed lookup cannot tell them
+apart — the trap [METHOD.md](../METHOD.md) already records for this corpus.
+Ordering resolves them: index 12 is `ptlogo_back2eff5` (`0x8832`, bit **set**),
+index 14 is `ptlogo_back2eff` (`0x8830`, bit **clear**).
+
+So the documented counterexample is **real and correctly attributed** — now on
+evidence rather than on a guess between two same-sized sprites.
+
+### 🔴 Two candidate meanings, both refuted
+
+| hypothesis | verdict |
+|---|---|
+| bit ⟺ the name contains `eff` | **refuted** — `ptlogo_back2eff` is an `eff` name with the bit clear. All 10 bit-set sprites *are* `eff` names, so the implication holds one way only |
+| bit ⟺ the element is transient (gone before the screen settles) | **refuted** — `pteff03`/`pteff03a` carry the bit and run to `t=250`, ramping to `a=255` and holding, i.e. they persist |
+
+### 🟡 What the exception looks like up close
+
+`ptlogo_back2eff` and `ptlogo_back2eff5` are the same size and the same artwork,
+and differ in **two** header words:
+
+```
+ptlogo_back2eff5  +0x04 00008832   +0x08 00008083   (layer key 32899, bit SET)
+ptlogo_back2eff   +0x04 00008830   +0x08 00008081   (layer key 32897, bit clear)
+```
+
+⚠️ They are **not** duplicates: pixel-compared, `max abs diff 21`. Their alpha
+summaries are identical to one decimal (4.5 % opaque, 86.7 % clear, mean 19.3),
+which is precisely why the summaries were not trusted — two different renditions
+of one image at one size.
+
+So the bit tracks something that also distinguishes two versions of the same
+artwork, alongside a different layer key. ❔ **Still not diagnosed**, but the
+search space is smaller by two and the attribution underneath it is now sound.