docs: the splash .prm measured -- and its paint order is a sequence, not depth

ui-prm-primitives recorded that where a .prm paints on a screen without a
measured order is unsolved. For the developer splash it is now measured.

Every frame opens with two full-screen draws before any sprite. The
second is untextured in all 212 frames with a constant vertex colour of
FF000000 -- opaque black -- matching palogo_eff0.prm's declaration
exactly: kind 0x10, pivot (640,360) -> 1280x720, one keyframe, a = 255.
So the splash backdrop is an opaque black full-screen quad from the
bundle itself, painted behind every sprite, which is why a splash render
needs --black rather than the default backdrop.

Not a general rule, and said so: the measured main-menu order puts
pteff02.prm at position 4 and pteff00.prm LAST, the latter being the
screen-transition fade.

And a correction to an existing row. measured_paint_order returns
[0, 2, 4, 6, 1, 3, 5] for the splash, described as "the .prm, then all
three glows, then the three logos". But the glows and the logos never
appear in the same frame -- 0 overlapping frames in 235 -- and two
elements that never co-occur have no observable relative depth. Between
those halves the vector records the order they were SEEN IN, not a
front-to-back relationship.

That does not make the render wrong, and element 0 is a real depth
observation since the .prm co-occurs with everything. But the type of the
claim matters: reading the vector as depth invites compositing all seven
elements at once, which is exactly what does not reproduce the screen.

METHOD: two things that never co-occur have no observable relative order;
when recording an order, note which pairs actually appeared together.

docs/re/METHOD.md

@@ -826,3 +826,11 @@ 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.

docs/re/REFUTED.md

@@ -595,3 +595,9 @@ 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)

docs/re/structures/ui-prm-primitives.md

@@ -174,3 +174,54 @@ have never been measured, so they are not in the table.
 * ❔ **The 8 non-full-screen ones**, including two with a zero dimension.
 * 🟡 `kind = 0x3010` (38 elements) is `0x10` plus `0x3000`, the button-record
   bits — a primitive that is part of a button. Unexamined.
+
+---
+
+## ✅ Measured on the splash: the `.prm` paints FIRST, full-screen, opaque black
+
+**2026-08-29.** This page recorded that where a `.prm` paints "on a screen
+without a measured order is unsolved". For the developer splash it is now
+measured, from the 235-frame draw capture.
+
+Every frame begins with two full-screen draws before any sprite:
+
+```
+f120: [1280x720]  [1280x720]  [499x241] …
+        ^clear      ^this one
+```
+
+The second is **untextured** in all **212** frames, with a constant vertex colour
+of **`FF000000`** — opaque black. That matches `palogo_eff0.prm`'s declaration
+exactly:
+
+| declared | observed |
+|---|---|
+| `kind = 0x10` (the primitive marker) | untextured draw |
+| pivot (640,360) → **1280×720** | 1280×720 quad |
+| **one** keyframe, `a = 255` | constant across 212 frames |
+| — | vertex colour `FF000000` |
+
+So the splash's backdrop is an **opaque black full-screen quad from the bundle
+itself**, painted behind every sprite — not a clear colour, which is why our
+splash renders need `--black` to match.
+
+⚠️ **Not a general rule.** The measured *main menu* order puts `pteff02.prm` at
+position 4 and `pteff00.prm` **last** — that one is the screen-transition fade.
+A `.prm` paints where its screen's order says; the splash's happens to be first.
+
+## ⚠️ And the splash's "measured paint order" is a SEQUENCE, not a depth order
+
+`measured_paint_order` returns `[0, 2, 4, 6, 1, 3, 5]` for the splash, commented
+*"the full-screen `.prm`, then all three glows, then the three logos"*.
+
+The draw capture shows the glows and the logos **never appear in the same frame**
+— 0 overlapping frames in 235 ([group start time](ui-group-start-time.md)). Two
+elements that never co-occur have **no observable relative depth**. What that
+vector records between its glow half and its logo half is the *temporal* order
+they were seen in, not a front-to-back relationship.
+
+🟡 This does not make the render wrong — compositing them in that order is
+harmless, and the ✅ for element 0 (the `.prm` first) *is* a real depth
+observation, since it co-occurs with everything. But the type of the claim
+matters for a consumer: **treating the vector as depth invites compositing all
+seven elements at once, which is exactly what does not reproduce the screen.**