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/METHOD.md

@@ -564,3 +564,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   elements paints identically either way. Reporting 15 would have overstated the
   risk by 7×; the useful number is the one filtered by whether the difference can
   reach a pixel.
+* **An exhaustive field search needs a positive control, or "found nothing" is
+  worthless.** Scanning a header for a field that reproduces a measured ordering
+  returned zero hits — which could equally mean the field is absent or the scan
+  is broken. Running the same scan against a *known* ordering (declaration order)
+  returned **64** hits, proving the scan finds ordering fields when they exist.
+  Only then is the zero a finding. The control costs four extra lines and turns a
+  silence into a negative with reach.