deps: bump the pin to f817dd5 -- the menu screens get their background

WHAT I WANTED FROM IT: 56cc7ac, "a RATC child's name is stated, not inferred".
A child was named by scanning backwards for the last printable run of bytes
before its magic. For `pteff05.t32` the three trailing payload bytes are
38 41 58 = `8AX`, which beat the real name, so the child registered under a name
no element declares and resolved to no sprite.

`pteff05.t32` is the full-resolution background of all five menu screens.

Every menu render this port has produced has been missing its background, and
P1 wrote that up as a fact about the disc -- "the bundle carries zero RATC
children for either, so there is no texture on the disc to export". That is
retracted in docs/DECISIONS.md rather than edited away.

The re-export is contained: six new sprites and nothing else. pteff05 on
main_menu/extras and their JP twins, pteff04 on both titles. Each gains a
`sprite` line and moves `layer_source` from "implied" to "sprite" -- the layer
key is now read from the file instead of the decoders' table of keys measured
off the running game, which is the ratchet turning the right way.

pteff05.png is 1280x720; ptbase.png, which had been carrying the background
alone, is 640x360 drawn at 200 %.

Measured against the live capture rather than the other renderer: settled
main_menu RMSE 8.05 % -> 5.92 %. The reference renderer was missing the same
element for the same reason, so no renderer-vs-renderer diff could have found
this -- the third time a capture has caught something both renderers agreed on.

Cargo.lock

@@ -959,7 +959,7 @@ dependencies = [
 [[package]]
 name = "sylpheed-formats"
 version = "0.1.0"
-source = "git+https://git.mc02.dev/fabi/Syplheed-Reborn.git?rev=5414db3#5414db34bfc0d0b0743e07e6e89f345540dc2e94"
+source = "git+https://git.mc02.dev/fabi/Syplheed-Reborn.git?rev=f817dd5#f817dd59393b1437d4ea70b58124c1309f6c076f"
 dependencies = [
  "anyhow",
  "binrw",

crates/sylpheed-export/Cargo.toml

@@ -14,6 +14,17 @@ license.workspace = true
 # is not one archive entry (segment-spanning reads, multi-sub-wave banks, and the
 # continuous cutscene-voice stream). Do not re-derive those here.
 #
+# Pin moved 5414db3 -> f817dd5 on 2026-08-29. WHAT I WANTED FROM IT: `56cc7ac`,
+# "a RATC child's name is stated, not inferred". A child was named by scanning
+# backwards for the last printable run before its magic; for `pteff05.t32` the
+# three trailing payload bytes are `38 41 58` = `8AX` and beat the real name, so
+# the FULL-RESOLUTION BACKGROUND OF ALL FIVE MENU SCREENS registered under a
+# name no element declares and resolved to no sprite. This port exported those
+# screens without their background and said so in every render as "pteff05 (no
+# sprite in the export)" -- which docs/DECISIONS.md then wrote up as correct.
+# It was not. f817dd5 is the last commit touching `crates/` on that branch.
+#
+# Previous pin note, kept because the reasoning still holds:
 # Pin moved 8b6dbcf -> 5414db3 on 2026-08-28. WHAT I WANTED FROM IT: the fix to
 # `ui_layout::rest()`. At 8b6dbcf a trailing run of identical keyframes was
 # always treated as the exit, so an element with no exit animation rested at its
@@ -21,7 +32,7 @@ license.workspace = true
 # which a capture of the running game plainly shows. 5414db3 is the revision at
 # which that fix carries its disc-wide check (30 of 13 991 elements move, 4
 # become visible, 0 become invisible), not merely the one where it was written.
-sylpheed-formats = { git = "https://git.mc02.dev/fabi/Syplheed-Reborn.git", rev = "5414db3" }
+sylpheed-formats = { git = "https://git.mc02.dev/fabi/Syplheed-Reborn.git", rev = "f817dd5" }
 
 serde      = { version = "1", features = ["derive"] }
 serde_json = "1"

docs/DECISIONS.md

@@ -266,12 +266,10 @@ texture", because both renderers use the declared pivot. That prediction held:
 the port and the CLI agree on every scaled element, and that agreement is **not
 evidence** about which anchor the game uses. It stays open.
 
-### `pteff05.t32` and `pteff04.t32` have no sprite, and that is correct
+### ~~`pteff05.t32` and `pteff04.t32` have no sprite, and that is correct~~
 
-Both renderers skip them. The bundle declares them and carries **zero** RATC
-children for either, so there is no texture on the disc to export — this is a
-property of the disc, not a gap in the exporter, and `ScreenView` reports it as
-`no sprite in the export` rather than dropping it silently.
+**RETRACTED 2026-08-29. This was wrong, and it was the most consequential thing
+on this page.** See "The menu had no background" below.
 
 ---
 
@@ -502,3 +500,66 @@ their diagnoses stand — a paint-order tie, two pixels, and nearest-neighbour
 sampling phase at 125 % scale. The title's swoosh defect the RE agent localised
 (drawn thick and white where the game draws it thin and pink) is untouched by
 any of this and remains P3's.
+
+---
+
+## The menu had no background, and P1 called that correct, 2026-08-29
+
+The pin moved `5414db3 → f817dd5` for `56cc7ac`, "a RATC child's name is stated,
+not inferred". `ratc::parse` had named each child by scanning backwards for the
+last printable run of bytes before its magic. For `pteff05.t32` the three
+trailing payload bytes are `38 41 58` — `8AX` — which beat the real name, so the
+child registered under a name no element declares and resolved to no sprite.
+
+`pteff05.t32` is the **full-resolution background of all five menu screens**.
+
+So every render this port has produced of a menu screen has been missing its
+background, and P1 wrote that up as a property of the disc: *"the bundle declares
+them and carries zero RATC children for either, so there is no texture on the
+disc to export."* That sentence was false. The bundle carries the child; the
+decoder was handing back the wrong name for it. Retracted above rather than
+edited away.
+
+### What the re-export shows
+
+Six new sprites and nothing else: `pteff05.png` on `main_menu`, `extras` and
+their Japanese twins, `pteff04.png` on both titles. Per screen the JSON gains a
+`sprite` line and `layer_source` moves `"implied" → "sprite"` — the layer key is
+now **read from the file** instead of taken from the decoders' table of keys
+measured off the running game. That is the derived/authored ratchet turning the
+right way, in the exporter rather than in `authored/`.
+
+`pteff05.png` is **1280×720**; `ptbase.png`, which had been carrying the
+background alone, is 640×360 drawn at 200 %. The screen was being shown its own
+art at half resolution.
+
+### Measured against the live capture, not against the other renderer
+
+Whole-frame RMSE of the settled `main_menu` against
+`captures/main-menu-oracle.png`:
+
+| | RMSE |
+|---|---|
+| before this pin | 8.05 % |
+| with the real background | **5.92 %** |
+
+A 26 % reduction, and it is the right kind of evidence: the reference renderer
+was missing the same element for the same reason, so a renderer-vs-renderer diff
+could not have found this. It is the third time on this project that the
+capture caught something both renderers agreed on — the bracket, the title dim
+quad, and now the background.
+
+`verify-screen` after the bump is unchanged in character: everything at 3–4/255
+except `title` (6, the paint-order tie) and `title_jp` (155, the sampling phase).
+Both renderers gained the background together.
+
+### One thing the comparison says that I did not expect
+
+Rendering with `--focus=ptbtn01`, which is how the capture was taken, makes the
+RMSE **worse** — 5.92 % → 7.00 %. The port *replaces* an element's sprite with
+its `*f` twin; `sylpheed-cli`'s own `--focus` is documented as drawing the
+focused record **over** the base element. Those are different operations, and
+the capture shows a ring marker beside `NEW GAME` that the port does not draw.
+
+This is P5's, not P2's, and it is not being guessed at here. Raised in
+`docs/BLOCKED.md`.