formats: two more measured paint orders, and the first independent confirmation

The three orders the derived rule was built from all live in GP_TITLE.pak, so
they cannot confirm it - the rule was fitted to them. These two are from
GP_SAVE_LOAD.pak, read off the running game now that the Canary threading fix
makes the main menu dependable.

The 9-element slot-list header composites EXACTLY as the sort predicts, on all 6
instances of it, and nothing about this screen was fed into the rule:

    measured  7 8 0 1 2 3 4 5 6
    derived   7 8 0 1 2 3 4 5 6

including TWO tied groups (0xb102 x2 and 0xb210 x5) that both come out in
declaration order, and the unkeyed pfeff00.prm fade quad last.

The 13-element save/load frame differs in exactly the two open questions and no
new ones: two unkeyed pfbase.tbm backgrounds paint FIRST where the sort puts the
keyless last - the splash's palogo_eff0.prm behaviour in a different file type,
so implied_layer_key now covers it - and the 0xb100 group of four paints
10,11,8,12 where declaration order is 8,10,11,12.

That second point is a SECOND screen with a mis-ordered tie, which is what the
question needed, and it immediately kills a candidate: 10 and 11 are kind=0x2002
while 8 and 12 are 0x0000, so "descending kind then declaration index"
reproduces 10,11,8,12 exactly - and then fails both title groups, where every
element of 0x8083 is kind 0 and where 0x80a0 would predict 2,3,4,5,0,1,7 against
a measured 0,2,4,7,1,3,5. Seven candidates refuted now.

16 disc tests green.

docs/re/structures/ui-paint-order-key.md

@@ -257,3 +257,69 @@ it is not. That is why the test reads pixels.
 
 So the residual error in the derived order is confined to **one element's blend
 on one screen**, and it is pinned: a change that makes it worse fails the test.
+
+
+## Two more measured orders — and the first independent confirmation (2026-08-19)
+
+The three orders the derived rule was built from all live in `GP_TITLE.pak`, so
+they cannot confirm it: the rule was fitted to them. These two are from
+`GP_SAVE_LOAD.pak`, read off the running game after the Canary threading fix made
+the main menu reachable ([capture](../captures/load-game-oracle.png)).
+
+### ✅ The slot-list header — exact, without being told anything
+
+`GP_SAVE_LOAD` ratc-indices 1/4/5/21/27, 9 elements:
+
+```
+measured  7 8 0 1 2 3 4 5 6
+derived   7 8 0 1 2 3 4 5 6      EXACT, on all 6 instances
+```
+
+| element | key |
+|---|---|
+| 7 `pffocus1.rat`, 8 `pfslot1f_scr.rat` | `0xb102` **tied ×2** |
+| 0 `pftitlebase` | `0xb200` |
+| 1–5 `pfeff11`…`pftitle1` | `0xb210` **tied ×5** |
+| 6 `pfeff00.prm` | none → last |
+
+Both tied groups come out in **declaration order**, which is what the stable sort
+gives, and the unkeyed fade quad lands last. Nothing about this screen was fed
+into the rule. It is the first evidence that the layer key is a real ordering
+mechanism rather than a description of three screens in one pak.
+
+### 🟡 The save/load frame — differs in exactly the two known ways
+
+`GP_SAVE_LOAD` ratc-index 18/24, 13 elements (`is_build` rejects it, so the
+compositor never sees it — but it is just as good as *evidence*):
+
+```
+measured  0 1 2 3 4 5 6 7 10 11 8 12 9
+derived   2 3 4 5 6 7 8 10 11 12 9 0 1
+```
+
+1. **Unkeyed elements paint first, not last.** Elements 0 and 1 are
+   `pfbase.tbm` — a `.tbm`, not a `.prm`, with no sprite and no key — and the
+   game paints them before everything else. Exactly the splash's
+   `palogo_eff0.prm` behaviour in a different file type, so `implied_layer_key`
+   now covers it and the layer-key sequences agree.
+2. **A tied group in a non-declaration order.** `0xb100` holds 8 `pfwin`,
+   10 `pfbtn0`, 11 `pfbtn1`, 12 `pfmsg`, and the game paints
+   **10, 11, 8, 12**.
+
+That second point is the tie-break question again — and it is now on a *second*
+screen, which is what it needed.
+
+### 🔴 Refuted: the tie-break is not `kind`
+
+The new group is suggestive: 10 and 11 are `kind = 0x2002` and 8 and 12 are
+`0x0000`, so "descending `kind`, then declaration index" reproduces
+`10, 11, 8, 12` exactly. It does not survive the title:
+
+* `0x8083` ×5 — every element is `kind = 0x0000`, so the rule predicts
+  declaration order `14,15,16,17,18`; the game paints `14,15,18,16,17`.
+* `0x80a0` ×7 — kinds are `0x0` and `0x4`, so the rule predicts
+  `2,3,4,5` then `0,1,7`; the game paints `0,2,4,7,1,3,5`.
+
+So `kind` is not it either, and the count of refuted candidates is now seven:
+declaration order, RATC child order, first keyframe time, resting time, resting
+X/Y, the `T8aD` header words, and `kind`.