re: census the T8aD paint-order key -- it is pak-local, not a global vocabulary

The page rested on twelve values from two screens.  This walks all 4525 sprites
on the disc.

  * The field is a u16 at +0x0A.  The upper half of the 32-bit word the page
    reads is zero in 4525/4525.  Nothing above changes -- 0x00008100 sorts the
    same as 0x8100 -- but a future value with the high half set would mean
    something had been misread rather than that the layer got deeper.
  * It is an enumeration: 45 values for 4525 sprites, one of which (0x8100)
    covers 1188 of them.
  * The reading worth trying -- a global layer vocabulary shared across the UI
    -- is refuted.  Only 4 of 45 keys cross a pak family and 33 of 45 live only
    in GP_MAIN_GAME_2D; every other pak owns a narrow high-byte band (0x90-0x94
    for the in-game overlays, 0xa4 mission log, 0xb1-0xb2 save/load).  A screen
    that owns one or two keys is not ordering itself with them.

That supports "group id in the high bits, order in the low bits", which is what
the page already suspected, but it does NOT test it: paint order has been
measured on two screens and both are inside GP_MAIN_GAME_2D, so there is no
ground truth to check the split against.  Left amber.

The first number I got was 37/45 shared, which would have supported precisely
the wrong conclusion.  It came from counting paks instead of pak families: the
six GP_MAIN_GAME_*2D paks are the same screens in six languages and their key
sets are byte-for-byte identical.  Recorded on the page, because the shape
recurs -- a corpus with near-duplicate members manufactures agreement.

docs/re/BACKLOG.md

@@ -143,6 +143,17 @@ where translucent sprites overlap.
 * ❔ What the field's bits mean — `0x8000`/`0x80a0`/`0xa110` look like flag words
   with a layer in some bits, not a plain depth. Sorting the whole word works on
   both measured screens; which bits carry the layer is unknown.
+  **Censused 2026-08-26** over all **4 525** disc sprites
+  (`tools/re-capture/paint_key_census.py`): ✅ the field is a **`u16` at `+0x0A`**
+  (upper half zero **4 525/4 525**), ✅ it is an **enumeration — 45 values**, and
+  🔴 **it is pak-local, so it is not a global layer vocabulary**: only **4/45**
+  keys cross a pak family and **33/45** live only in `GP_MAIN_GAME_2D`, each
+  other pak owning a narrow high-byte band (`0x90`–`0x94` overlays, `0xa4`
+  mission log, `0xb1`–`0xb2` save/load). Supports "group id in the high bits,
+  order in the low bits" but does **not** test it — both measured screens are
+  inside one pak. ⚠️ My first count said 37/45 shared; that was the six
+  *language* copies of `GP_MAIN_GAME_2D` (identical key sets) counted as six
+  paks, and it pointed at the opposite conclusion.
 * ❔ A third measured permutation, to promote "holds on two" to a rule. The
   cheapest is a screen whose object is resident at the same time as the title's.
 * ❔ 341 builds now composite in an order no capture has checked.