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.