docs/re: the title screen's paint order, measured from the draw stream

BACKLOG's UI-ordering item ended at "the next step is no longer static — it is a
per-draw capture of the title screen showing the order the game submits". That
capture now exists.

The order, in submission order: a full-screen background layer, a rotated effect
pair, a second full-screen layer, ptlogo_back2eff + ptlogo_back2, ptlogo1 +
ptlogo_tm, ptlogo2, ptcopyright, and the PRESS (A) BUTTON plate — declaration
indices 13, 22|24, 23, 0, 11, 1, 28, and then two elements that are not in that
build at all.

Two more candidate orderings die on it (keyframe start time, resting-keyframe
time), and one structural fact reframes the item: the visible screen composites
TWO bundles — build 7 plus the one-element build 2 that is the button — so no
single build's element table can be the paint order whatever its order. The
button's quad lands at (384,551) against a declared rest of (383,550), which is
a one-pixel agreement between the static placement decode and the running game
on a bundle nothing had checked.

INDEX's "the screen's draw list is the bundle's declaration table (back-to-front)"
is demoted in place rather than edited away.

Still open and said so: the rule that produces the order; three of twelve quads
unidentified; one screen only.

docs/re/BACKLOG.md

@@ -122,6 +122,27 @@ the other two are — and therefore a `build-canary` run. That is the cost to
 state up front rather than discover halfway in; it is not a container
 limitation, just a long build plus a title-screen run.
 
+### 2026-08-18 (later) — the hook was built and run; the order is now measured
+
+`log_ui_draws` exists (Canary branch `auto/re-ui-draw-order`), and the title
+screen's paint order is **ground truth** rather than a candidate:
+[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md).
+
+Background first, then the `back2` glow pair, then `ptlogo1` + `ptlogo_tm`, then
+`ptlogo2`, then `ptcopyright`, then the `PRESS Ⓐ BUTTON` plate — i.e.
+declaration indices `13, 22|24, 23, 0, 11, 1, 28` and then two elements that are
+**not in build 7 at all**. Two more orderings die on that evidence (keyframe
+start time, resting-keyframe time), and one structural fact reframes the whole
+item: the screen composites **two bundles** (build 7 plus the one-element build
+2 that is the button), so no single build's element table can be the paint order
+whatever its order.
+
+**Still open, and now sharper:** the rule. The bundle's 60-byte declaration entry
+carries no depth field (dumped, above); the per-element `.rat` record has not
+been checked for one against this ground truth, and nothing yet explains how the
+two bundles are sequenced. Both are static questions again — the oracle side is
+answered.
+
 
 ## Capital ships assemble wrong in the viewer