docs/re: mark the paint-order item solved, and say what is left

The item that has been open through this whole run is answered: the paint order
is the screen object's reordered child array at +0x30, not any table in the file.
BACKLOG and INDEX now lead with that, and the investigation behind it is kept in
full underneath — most of it refutations, which is what made the answer findable.

What is left is stated in the same breath, because it is what the port needs:
deriving that order from the bundle without running the game. Until then the
viewer paints in declaration order and the title screen composites wrongly, which
is now a documented defect rather than a mystery.

docs/re/BACKLOG.md

@@ -6,6 +6,25 @@ unknown, what evidence exists, and what the first step would be. Move an item in
 
 ---
 
+## ✅ SOLVED (2026-08-19) — the paint order is a runtime child list, not a table in the file
+
+The screen object the game builds at load time holds **two** lists of its
+elements: the declaration-ordered array at `+0x08`, and a **reordered child array
+at `+0x30`** — and the second is the paint order. Read live off the title screen
+and checked against the draw capture: the seven nameable elements sit at child
+slots 0, 6, 7, 13, 16, 17, 22, strictly ascending, in exactly the captured order.
+See [`structures/ui-screen-runtime.md`](structures/ui-screen-runtime.md).
+
+**Still open, and it is what the port actually needs:** deriving that order from
+the bundle without running the game. The order is structured (elements sharing a
+sprite are adjacent; full-screen effects lead), so it looks derivable, but no
+rule has been found. Until then the viewer paints in declaration order and the
+title screen composites wrongly — a known, documented defect rather than a
+mystery.
+
+The investigation that got here follows, kept in full because most of it is
+refutations that were worth the cost.
+
 ## The declaration table is not a paint order on every screen
 
 **Found 2026-08-17**, building the Explorer's UI Screens browser on