docs/re: the title-screen oracle — what it settled, and what it refuted

`BACKLOG.md`'s "the declaration table is not a paint order on every screen" had
been reasoned about but never measured. It is now measured, and the entry says
so both ways.

Confirmed: a framebuffer capture of Canary on the title screen shows the
`PROJECT SYLPHEED` wordmarks over the full-screen background, so declaration
order is not the paint order there.

Refuted, and recorded rather than quietly dropped:

* the `0x10`-adjacency first step this entry proposed. The background *is* next
  to a `kind = 0x10` `.prm` on both screens that have one — but on opposite
  sides (`GP_TITLE` puts the background after it, `GP_MISSION_SELECT` before),
  so no rule keyed on the `.prm` orders both. `GP_READY_ROOM` and `GP_OPTIONS`
  cannot serve as the third and fourth witnesses: neither carries a `.prm` or a
  full-screen background at all.
* the placement-region group order and the RATC child order, as above.
* reverse declaration order, by the same capture — it would draw the background
  over the copyright line, which is visible.

And separated out: part of what the bad render showed was not ordering at all
but the pivot/scale defect fixed two commits back. `ui-rat-layout.md` gains that
rule, the correlation evidence, the unmeasured pivot-vs-centre gap, and the
disc-wide demotion of "pivot is exactly half the texture" (49 % agree, 37 % are
off by more than 16 px — `ptcopyright` is 694 px wide in the framebuffer and
`pivot*2` says 618).

Captures: `title-screen-oracle.png` (the game surface cropped out of the
emulator window at (1,45), 1:1, bottom 45 rows clipped by the display) and
`title-screen-composite-2026-08-18.png` beside it.

docs/re/BACKLOG.md

@@ -51,6 +51,55 @@ screen, and the per-element visibility toggles isolate a suspect element.
 otherwise — a screen whose background lands on top is showing you this bug, not
 a decode failure.
 
+### 2026-08-18 — measured against the running game; three orderings refuted, and half the symptom was a different bug
+
+**The premise is confirmed by the oracle**, which this entry had not had: a
+framebuffer capture of Canary on the title screen
+([`captures/title-screen-oracle.png`](captures/title-screen-oracle.png)) shows
+the `PROJECT SYLPHEED` wordmarks (elements 0–5) drawn **over** `ptbase2.t32`
+(element 13), which is a full-screen background. Declaration order is therefore
+not the paint order on this screen, and no reading of the element table changes
+that.
+
+**But part of what the render showed was not the paint order at all.** In the
+capture `ptbase2` covers the whole screen; the compositor drew it as a
+960×540-visible slab starting at (320,180), because a keyframe's `scale` was
+being grown from the keyframe's corner instead of about the declared **pivot**.
+Fixed, and pinned against the capture by cross-correlation (peak at (0,0)) — see
+[`structures/ui-rat-layout.md`](structures/ui-rat-layout.md). That was a real
+defect worth separating out: it moves **865** of the disc's 5 130 resting
+placements, on every screen, independently of any ordering question.
+
+**Three candidate orderings are now dead**, all cheaply:
+
+- **The placement region is not a second ordering.** Its keyframe groups carry an
+  explicit element index, so they *could* be stored in a different order — they
+  are not, on **every** build on the disc (`placement_region_order_is_never_a_second_ordering`,
+  >500 builds, identity every time).
+- **The RATC child order is not it either.** For the title build it is the
+  declaration order with the `.prm` elements absent — strictly less information,
+  and it has no place to put `ptbase2` other than where the table already puts it.
+- **Reverse declaration order is refuted by the same capture**: it would draw
+  `ptbase2` (13) over `ptcopyright` (28), and the copyright line is visible.
+
+**The `0x10`-adjacency first step was run, and it does not survive.** The
+background *is* adjacent to a `kind = 0x10` `.prm` element on both screens that
+have one — but on **opposite sides**. `GP_TITLE` build 7 is
+`12 pteff00.prm (0x10)`, `13 ptbase2.t32`, `14 pteff04.t32`;
+`GP_MISSION_SELECT` build 0 is `0 px_mission_base.tbm`, `1 px_mission_eff00.prm
+(0x10)`. So "the `.prm` opens a layer that draws beneath what precedes it" cannot
+place both, and no rule keyed on the `.prm`'s position orders the background.
+`GP_READY_ROOM` and `GP_OPTIONS` turned out not to be the third and fourth
+witnesses this entry hoped for: neither of their largest builds carries a `.prm`
+or a full-screen background at all, so they cannot discriminate.
+
+**What is still open, stated plainly:** nothing in the bundle has been found that
+orders element 13 behind elements 0–5. Every ordering the file itself carries is
+now either identical to the declaration table or refuted by the capture. The next
+step is no longer static — it is either the guest code that walks this table, or a
+per-draw capture of the title screen showing the order the game submits.
+
+
 ## Capital ships assemble wrong in the viewer
 
 **Reported:** 2026-07-30, by the user. **Status:** ✅ **format-side cause found and