docs/re: the paint order is deterministic, and the 7-element screen is the logo splash

Two things this iteration, both of which change what is worth doing next.

The order is DETERMINISTIC: two independent boots give byte-for-byte identical
permutations for both live screens. That kills the hypothesis that the child list
is built in I/O-completion order — which mattered, because a run-dependent list
would have made deriving a rule pointless. It is a pure function of the bundle.

And the 7-element bundle is identified by matching its pivots against every
7-element build on the disc: it is the developer-logo splash (GAME ARTS / SETA /
studio anima, GP_TITLE entries 11/14). With names attached, its paint order
0 2 4 6 1 3 5 reads as the full-screen .prm, then all three _eff glows, then all
three base logos — glow behind, logo on top.

That refines the earlier "grouped by sprite" reading and partly withdraws it:
here every element has its own sprite, so the grouping is by ROLE, not sprite
identity. The title build could not tell the two apart because its repeated logo
instances share both.

Still not derived: where the role comes from. No decoded field carries it, and
sorting on a "_eff" name suffix would be an odd thing for a loader to do.

docs/re/structures/ui-screen-runtime.md

@@ -153,15 +153,30 @@ Deriving the child order from the bundle is what the port needs, so the first
 step is data. Both live screen objects with more than one element, read off the
 title screen:
 
-**A 7-element bundle** (pivots `(640,360) (250,36) (260,46) (120,44) (130,55)
-(194,68) (204,78)` — three pairs 10 px apart plus a full-screen layer):
+**The developer-logo splash** — `GP_TITLE.pak` entries 11/14, identified by
+matching its pivots against every 7-element build on the disc. It is the
+GAME ARTS / SETA / studio anima screen, i.e. the one the emulator-era Milestone 1
+worked on:
+
+```
+0 palogo_eff0.prm (640,360)   1 palogo_gamearts (250,36)   2 palogo_gamearts_eff (260,46)
+3 palogo_seta (120,44)        4 palogo_seta_eff (130,55)
+5 palogo_anima (194,68)       6 palogo_anima_eff (204,78)
+```
 
 ```
 paint order (child slots): 0 2 4 6 1 3 5
 ```
 
-— the **even** declaration indices in order, then the **odd** ones. A stable
-partition into two groups, nothing more.
+— which, with the names, reads as **the full-screen `.prm`, then all three
+`_eff` glows, then all three base logos**. The glow behind, the logo on top:
+a semantic grouping, and one that the declaration table interleaves
+(base, glow, base, glow, …).
+
+**This refines the "grouped by sprite" reading.** Here every element has its own
+sprite, so the grouping cannot be by sprite identity — it is by *role*. In the
+title build the two readings coincide (the three `ptlogo1` instances share both a
+sprite and a role), so that build alone could not tell them apart.
 
 **The 24-element title build:**
 
@@ -191,6 +206,19 @@ paint order: 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7 1 3 5 22 23 21 8
   (`ptbase2` is RATC child 4 and paints first; `ptlogo1` is child 0 and paints
   fourteenth).
 
-**Not settled:** the rule. Two permutations are enough to kill the simple
-candidates and not enough to build the real one — the group *contents* are
-explained (same sprite), the group *order* is not.
+### The order is deterministic
+
+Two independent boots, the same screens: **byte-for-byte identical
+permutations** (and identical object addresses). So the child list is not built
+in I/O-completion order or anything else run-dependent — it is a pure function of
+the bundle, and therefore derivable in principle. That was worth testing before
+hunting for a rule, because a load-order-dependent list would have made the hunt
+pointless.
+
+**Not settled:** the rule itself. What is known is that the list groups elements
+by role — glows before bases, instances beside their template — which the
+declaration table interleaves. What is not known is where that role comes from:
+no decoded field carries it, and the names (`_eff`) are suggestive but a loader
+sorting on a name suffix would be unusual. The next step is the loader — the code
+that appends to `+0x30` — which is now worth reading precisely *because* the
+order is deterministic.