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.

crates/sylpheed-formats/src/ui_layout.rs

@@ -698,7 +698,11 @@ pub fn sprite_layer_key(build: &UiBuild, bundle: &[u8], el: &Element) -> Option<
 /// — and why `ComposeOptions::include_primitives` is still off by default.
 pub fn implied_layer_key(name: &str) -> Option<u32> {
     Some(match name {
-        "palogo_eff0.prm" => 0x0000,
+        // Full-screen backdrops, measured painting FIRST on their screens.
+        // `pfbase.tbm` is not a `.prm` at all — a `.tbm` with no sprite and no
+        // key — but it behaves identically: the save/load screen paints it and
+        // its `kind = 0x3004` instance before everything else.
+        "palogo_eff0.prm" | "pfbase.tbm" => 0x0000,
         "pteff04.t32" | "pteff05.t32" => 0x8020,
         "pteff02.prm" => 0x8030,
         "pteff00.prm" => 0xffff_fffe,