docs/re: point the paint-order item at the derivation

The entry said deriving the order from the bundle was open. A key has been found
— the T8aD header word at +0x08 — so the entry now says that, what it does not
cover (ties, bit meanings), and that it is not wired into the compositor yet.

docs/re/BACKLOG.md

@@ -28,8 +28,15 @@ rather than only the CLI's `screen render` — checked in `iso_loader.rs`
 (`compose_screen`), which also keeps its element table in declaration order, so
 the per-element visibility toggles still line up.
 
-**Still open:** deriving the order from the bundle for screens nobody has
-captured. It is not in the declaration entry, the placement region or the runtime
+**Derivation found (2026-08-19)**: the order sorts by the word at **`+0x08` of
+the T8aD sprite header** — non-decreasing in paint order on both measured
+screens, with no inversion, and on the splash it explains the whole permutation.
+See [`structures/ui-paint-order-key.md`](structures/ui-paint-order-key.md). Not
+yet wired into the compositor, and its ties are unexplained.
+
+**Still open:** the tie-break, what the field's bits mean, and a third measured
+screen to promote this from "holds on two" to a rule. Also still open, and
+unaffected by the key: deriving the order for screens nobody has captured. It is not in the declaration entry, the placement region or the runtime
 element record (all measured); what remains is the loader that builds the child
 list. The order is deterministic across boots, so a rule exists — it just has not
 been found, and every screen without a measured order still paints in declaration