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

@@ -139,9 +139,16 @@ See [`structures/ui-composable-bundles.md`](structures/ui-composable-bundles.md)
   and it is pinned by a test. The third pair (`ptlogo2` vs `ptlogo_tm`) overlaps
   by bounding box but shares no opaque pixel; a box test called it a defect and
   the alpha says otherwise.
-  **Next:** it is one element on one screen, so the cheap move is a fourth
-  measured screen with a tied group — not more static guessing at fields that
-  have all now been checked. 🔴 **Attempted 2026-08-19 and blocked:** advancing
+  ✅ **Fourth and fifth screens measured (2026-08-19)**, from `GP_SAVE_LOAD`,
+  reachable now that the Canary threading fix makes the menu dependable. The
+  9-element slot-list header is **EXACT** under the derived rule — two tied
+  groups both in declaration order, unkeyed `.prm` last — and it is the first
+  screen outside `GP_TITLE.pak`, so it *confirms* the rule rather than being
+  fitted to it. The 13-element save/load frame differs in exactly the two known
+  ways: unkeyed `pfbase.tbm` backgrounds paint **first** (now covered by
+  `implied_layer_key`), and the `0xb100` group of four paints `10,11,8,12`.
+  🔴 **Refuted: the tie-break is not `kind`.** "Descending kind" reproduces
+  `10,11,8,12` exactly but fails both title groups. Seven candidates refuted now. 🔴 **Attempted 2026-08-19 and blocked:** advancing
   past the title is intermittent — **1 success in 3 attempts**, same binary,
   same profile, same procedure. ✅ **And now diagnosed one layer deeper:** the
   title *does* act on Ⓐ — the press spawns a slot-`(1F)` loader thread (exactly