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/re/REFUTED.md

@@ -595,9 +595,13 @@ neighbourhood, not just the line.
   glows — so whichever was active, a subset of its elements was drawn at a time.
   Selective activation is reinstated on evidence.
   [`ui-group-start-time.md`](structures/ui-group-start-time.md)
-* "the splash's `measured_paint_order` records a front-to-back depth order" →
-  **mis-typed.** Its glows and logos never share a frame (0 overlap in 235), so
-  their relative depth was never observable — between those halves the vector
-  records the *temporal* order they were seen in. Element 0 (`palogo_eff0.prm`)
-  is a genuine depth observation, because it co-occurs with everything.
-  [`ui-prm-primitives.md`](structures/ui-prm-primitives.md)
+* ~~"the splash's `measured_paint_order` records a front-to-back depth order" →
+  mis-typed; between its glow and logo halves it records only the temporal order
+  they were seen in."~~ → **that refutation is itself refuted (same day).** The
+  vector is a read of the runtime **child array** (`ui-screen-runtime.md`:
+  "paint order (child slots)"), not of the draw capture, so co-occurrence does
+  not bear on it; and the halves carry *distinct* T8aD layer keys
+  (`0xa100` < `0xa110`, `paint_order_audit`: 0 same-key ties), so the file orders
+  them regardless. The no-overlap measurement was correct; the inference from it
+  was not. What survives: a capture of this screen can only cross-check the order
+  *within* each half. [`ui-prm-primitives.md`](structures/ui-prm-primitives.md)