re(ui): the paint-order tie-break is undecodable from the bundle

Q3 was delivered as "decoded: a u16 layer key at +0x0A". The audit last
iteration showed the key does not fully order a screen -- elements
sharing a key are tied, and on the title that tie-break decides two total
occlusions. This searches for what breaks the tie, and closes it as a
negative with reach.

The game paints the five tied ptlogo_back2eff glows in the order
eff1, eff2, eff5, eff3, eff4. Three static structures were searched:

1. The declaration table. Entries 14-18 are byte-identical apart from the
   pivot, which is only half the sprite's own size.

2. The T8aD headers. All five carry identical +0x04 (0x8832) and
   identical +0x08/+0x0A (32899, the key itself), differing only in
   position and tile count. Searched exhaustively -- every offset
   0x00-0x7f, u8/u16/u32, ascending and descending:

     fields sorting to the MEASURED order:              0
     fields sorting to the DECLARATION order (control): 64

   The control is the point: 64 fields can be found that reproduce a
   known ordering, so the scan finds ordering fields when they exist. It
   finds none for the order the game uses.

3. The RATC child order -- a genuinely different permutation on other
   screens -- gives eff1..eff5 here, declaration order again.

All three static orderings give eff1..eff5; the game gives eff1,2,5,3,4.
That agrees with ui-screen-runtime's conclusion from the other direction:
the game builds a reordered child list at load time and paints that.

Q3 now reads honestly: the layer key is decoded and orders 4 of the 5
measured bundles exactly; the tie-break within a key is undecodable, and
a consumer must use a measured order or accept declaration index as an
arbitrary stand-in. The port's exposure remains 2 overlapping tied pairs
on EXTRAS.

METHOD: an exhaustive field search needs a positive control, or "found
nothing" is worthless.

docs/re/REFUTED.md

@@ -457,3 +457,10 @@ neighbourhood, not just the line.
   repeating one stale frame; cross-checked, it read surface mean 5.21 where
   `import` read 125.65 at the same moment. A dense negative from a frozen stream
   is not a negative. [`capture-harness-status.md`](capture-harness-status.md)
+* "the `T8aD` layer key fully determines a screen's paint order" → **refuted, and
+  the remainder is undecodable.** Elements sharing a key are tied; on the title
+  the game paints the five tied `ptlogo_back2eff` glows `1,2,5,3,4` while the
+  declaration table, the RATC child order and **every** field in the `T8aD`
+  header (exhaustive 0x00–0x7f, u8/u16/u32, both directions — 0 matches against
+  64 for the declaration-order control) all give `1,2,3,4,5`.
+  [`ui-paint-order-derived-check.md`](structures/ui-paint-order-derived-check.md)