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/METHOD.md

@@ -826,11 +826,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   four-entry enumeration showed none exists, and the question closed statically.
   A hypothesis that predicts an artefact can be killed by looking for the
   artefact, which is often far cheaper than measuring the behaviour.
-* **Two things that never co-occur have no observable relative order.** A
-  "measured paint order" recorded from a running game looks like depth
-  information throughout, but between elements that never share a frame it can
-  only be the sequence they were *seen in*. The splash's vector mixes both kinds
-  — element 0 is real depth (it co-occurs with everything), the glow/logo split
-  is not — and the difference matters, because reading it as depth invites
-  compositing every element at once. When recording an order, note which pairs
-  actually appeared together.
+* **Check what a "measured" value was measured *from* before reasoning about
+  its limits.** Two things that never co-occur have no observable relative order
+  — true, and a real limit on any order read from a *draw capture*. I applied it
+  to the splash's paint order and withdrew it hours later: that vector is a read
+  of the runtime **child array**, which has a definite order whether or not its
+  children are ever drawn together, and the two halves in question also carry
+  distinct static layer keys. Both the provenance and an independent static field
+  said the order was real. The general trap is not the co-occurrence rule, it is
+  applying a source-specific limit to a value from a different source: the word
+  "measured" covers several kinds of evidence, and the page that recorded it
+  usually says which — `ui-screen-runtime.md` said "child slots" in as many
+  words. Read that line before building an argument on top of it.