re: Q3 was already answered in docs/re -- deliver it, and test it on EXTRAS

The handoff had Q3 as "runtime-solved only". It is not: the layer key at
+0x0A of the T8aD sprite header, stable-sorted, is a file-derivable paint
order, already checked against five measured orders and already driving
the compositor for every build on the disc. That answer had simply never
reached the page the port agent reads.

The new evidence is EXTRAS -- the first screen composited from the rule
alone and scored against a framebuffer capture the rule had never seen.
0.9620 at zero shift, against a same-tooling control of 0.9657 on the
screen the rule was fitted to.

Written down with its limit rather than its headline: align_to_capture
correlates edges, and a paint-order change moves blends, not edges, by
=<45/255 on a few per cent of pixels. So the score is evidence for
placement and only CONSISTENT with the order. The sharp A/B needs a
rebuild and is named in the doc instead of being claimed.

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

@@ -395,3 +395,50 @@ Three published numbers on this page were wrong the same way: each was computed
 over a population I had not checked was the population in question — the six
 language copies, then the top-level-only sprites, then the size of that gap. The
 analysis was never the problem. **Check the sampling frame before the statistic.**
+
+## `EXTRAS` — the derived order against a capture nobody had taken (2026-08-28)
+
+The five orders above are all **measured**: the derived rule is checked against a
+live child list. This one is the other direction — a screen with **no measured
+order at all**, composited purely from the derived rule and scored against a
+framebuffer capture taken the same day
+([capture](../captures/title-builds/live-extras.png),
+[composite](../captures/ui-layout/extras-composited.png)).
+
+`GP_TITLE.pak` build 6, 18 elements, two `.prm` primitives:
+
+```
+sylpheed-cli screen render --build 6 --black --primitives GP_TITLE.pak extras.png
+align_to_capture.py live-extras.png extras.png --region 150 100 1150 600
+```
+
+| composite | best shift | score |
+|---|---|---|
+| **build 6, `--black --primitives`** | **(0, 0)** | **0.9620** |
+| build 6, no primitives | (0, 0) | 0.9576 |
+| *control:* main menu vs `main-menu-oracle.png`, same tooling | (0, 0) | 0.9657 |
+
+The control was run first and reproduces the screen this rule was fitted to, so
+the harness is known-good before the new screen is scored. `EXTRAS` lands within
+0.004 of it, at zero shift, with the primitives helping rather than hurting.
+
+### ⚠️ What this does and does not show
+
+**It does show** that every other part of the stack transfers to an unfitted
+screen: element enumeration, resting pose, pivots, `fade` alpha, and that the
+two primitives land somewhere harmless under the derived `implied_layer_key`.
+
+**It does not show that the paint order is right.** `align_to_capture.py`
+correlates *gradient magnitude* — edges — and a paint-order change moves blend
+values, not edges. The earlier derived-vs-declaration A/B on the pause menu and
+main menu measured exactly that: 1.1–3.8 % of pixels differing by ≤45/255, in
+translucent overlaps. A score computed this way cannot see a difference that
+size, so **0.9620 is evidence for placement and only consistent with the order.**
+
+**The sharp test, not run.** Composite build 6 twice — the committed derived
+order, and `compose` temporarily reverted to declaration order — and diff both
+against the capture over the pixels where they disagree. That needs a rebuild of
+`sylpheed-formats`, which is why it is named here rather than done; it is the
+same A/B this page already ran on the two screens that had oracles, and `EXTRAS`
+would be the first screen where the two orders can be judged against ground
+truth rather than declared indistinguishable.