docs: withdraw yesterday's "paint order is a sequence" -- wrong source

Last iteration I claimed the splash's measured_paint_order [0,2,4,6,1,3,5]
records, between its glow and logo halves, the temporal order they were
seen in rather than depth -- because the halves never share a frame.

The no-overlap measurement is right (glows f94-115, logos f116-211). The
inference is wrong, on two independent grounds:

  * Wrong source. That vector is not a read of the draw capture. It is a
    read of the live screen object's CHILD ARRAY -- ui-screen-runtime.md
    records it literally as "paint order (child slots)". A child list has
    a definite order whether or not its children are ever drawn together,
    so co-occurrence does not bear on it. The capture was the CHECK.
  * The order is in the file anyway. paint_order_audit on GP_TITLE entry
    11: derived == measured, 0 inverted pairs, 0 same-layer-key ties. The
    glows and logos carry distinct T8aD keys (0xa100 < 0xa110), so the
    file orders the halves statically, no capture involved.

I asked the question that started this iteration -- do the title and menu
orders have the same problem -- and the answer is that none of the three
does, for the same reason.

What survives is narrower and now recorded with numbers: how much of each
order its capture actually cross-checks. The title capture is stable (8
draws / 12 quads / 5 textures, identical in all five captured frames
across two logs) and confirms 7 of 24 positions; the menu capture is not
(texture 0x11C30000 present in frame 0, gone by frame 3); the splash
capture cannot cross-check its middle at all.

A counting trap worth the tool: count QUADS, not draws. The menu's draw 9
is indices=24 -- six quads batched from one texture. Counting draws reads
9 where 16 are on screen, and an earlier pass of this analysis briefly
"found" three quads for six declarations that way and concluded elements
were missing. They were batched.

METHOD: check what a "measured" value was measured FROM before reasoning
about its limits. The co-occurrence rule is real, and it is specific to
orders read from draw captures.

docs/port/HANDOFF.md

@@ -393,12 +393,18 @@ authored version can be deleted.
   `a=255`). That is why a splash render needs `--black` rather than the default
   backdrop. ⚠️ Not a general rule: the main menu's measured order puts one `.prm`
   at position 4 and the other **last** (the transition fade).
-  ⚠️ **And the splash's recorded paint order `[0,2,4,6,1,3,5]` is a temporal
-  sequence, not a depth order.** Its glows and logos never share a frame, so
-  their relative depth was never observable — the vector records the order they
-  were *seen in*. Element 0 (the `.prm`) is a genuine depth observation because it
-  co-occurs with everything. **Do not read the rest as depth and composite all
-  seven at once** — that is precisely what fails to reproduce the screen.
+  ✅ **The splash's recorded paint order `[0,2,4,6,1,3,5]` is a real depth
+  order** — read off the runtime child array, and independently backed by the
+  static layer key (glows `0xa100` sort before logos `0xa110`;
+  `paint_order_audit` reports derived == measured, 0 ties). A same-day claim on
+  this page that it was "a temporal sequence, not depth" was **withdrawn**; see
+  the ❌ section in the linked page for why, if you read it before the fix.
+  ⚠️ Separately and still true — and it is an **activation** fact, not a
+  paint-order one: the splash's glows and logos are never on screen together
+  (glows f94–115, logos f116–211,
+  [timeline](../re/data/splash-phase-timeline.txt)). Compositing all seven at
+  once reproduces no frame of the real screen. Depth says *what covers what*;
+  it does not say *what is up*.
   [`structures/ui-prm-primitives.md`](../re/structures/ui-prm-primitives.md)
 
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is