re: retract the paint-key census and redo it over all 21 184 sprites

The census filtered pak entries whose own first four bytes are T8aD.  A sprite
is usually a child of a RATC bundle, and a bundle entry's magic is RATC, so a
top-level magic filter cannot see one:

    top-level T8aD entries (counted)    4 525 sprites,  45 keys
    T8aD inside RATC bundles (missed)  16 659 sprites, 204 keys
    both                               21 184 sprites, 216 keys

171 of the 216 keys exist only inside bundles.  The sharpest statement of the
error: that census never saw GP_TITLE.pak at all -- the pak holding both of the
screens this page's entire evidence comes from.

Retracted: "45 values", "the keys are pak-local", "each auxiliary pak occupies
its own narrow high-byte band".  On the full population 68/216 keys (31%, not
9%) cross a pak family and the per-pak ranges overlap heavily -- GP_BUNK
0x8000-0xa110, GP_TITLE 0x8000-0xc150, GP_LEADERBOARD 0x8000-0xf100.  The tidy
banding was an artifact of seeing one or two keys per pak.  So the key looks
like a shared vocabulary, which is the opposite of what I published.

Survives, now on the full population: the field is a u16 at +0x0A (upper half
zero 21 184/21 184), and it is an enumeration (216 values for 21 184 sprites).

Three wrong numbers on this page now, all the same shape -- a statistic computed
over a population I had not checked was the population in question.  Stated once
at the end of the section rather than three times: check the sampling frame
before the statistic.

docs/re/BACKLOG.md

@@ -143,17 +143,20 @@ 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
+  **Censused 2026-08-26** over **all 21 184** 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.
+  (upper half zero **21 184/21 184**) and ✅ an **enumeration — 216 values**.
+  🔴 **"the keys are pak-local" is REFUTED** — **68/216 (31 %)** cross a pak
+  family and the per-pak ranges overlap heavily, so it looks like a shared
+  vocabulary, not a per-screen depth. ❔ Which bits carry the layer is still
+  unknown.
+  ⚠️ **A first version of this census was retracted.** It filtered pak entries on
+  a `T8aD` magic, but sprites are usually **`RATC` children** — it saw 4 525 of
+  21 184 sprites, 45 of 216 keys, and **not `GP_TITLE.pak` at all**, the pak both
+  measured screens come from. It reported "45 values" and "pak-local", both wrong.
+  A separate earlier slip on the same page counted the six *language* copies of
+  `GP_MAIN_GAME_2D` as six paks. Same shape each time: a statistic computed over
+  an unverified sampling frame.
 * ❔ 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.