docs/re: two ground-truth paint permutations, and four more refutations

Deriving the child order from the bundle is what the port needs, so this collects
data rather than guessing. Both multi-element screen objects live on the title:

* a 7-element bundle paints 0 2 4 6 1 3 5 — evens then odds, a stable partition;
* the 24-element title build paints 9 11 12 10 13 6 20 19 14 15 18 16 17 0 2 4 7
  1 3 5 22 23 21 8.

Two things the pair establishes. The list is GROUPED, not shuffled: elements
sharing a sprite are contiguous (ptlogo1's three instances at slots 13-15,
ptlogo2's at 17-19, the back2eff family at 8-12). And the five single-keyframe
elements lead — exactly elements 9,10,11,12,13 have one keyframe, and the list
opens with all five, which is a file-visible property.

Refuted on this data: first-keyframe time and resting time (back2eff1 starts at
52 and rests at 56, yet paints after back2 at 66/80), declaration order and its
reverse, and the RATC child order (ptbase2 is child 4 and paints first while
ptlogo1 is child 0 and paints fourteenth).

Not settled, and said so: the rule. The group CONTENTS are explained; the group
ORDER is not, and two permutations are too few to build it.

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

@@ -146,3 +146,51 @@ Until it is derived, a reimplementation has two honest options: hard-code the
 captured order for the screens that have been captured, or paint in declaration
 order and accept that the title screen composites wrongly. The first is what the
 evidence supports; the second is what the viewer does today.
+
+## Two ground-truth permutations, and what they rule out
+
+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):
+
+```
+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.
+
+**The 24-element title build:**
+
+```
+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
+```
+
+### What the pair shows
+
+* **The list is grouped, not shuffled.** Elements sharing a sprite are
+  contiguous: `ptlogo1`'s three instances (0,2,4) at slots 13–15, `ptlogo2`'s
+  (1,3,5) at 17–19, the `back2eff*` family at 8–12. The 7-element bundle's
+  even/odd split is the same phenomenon in miniature if its evens and odds are
+  two sprites.
+* **The five single-keyframe elements lead.** In the title build, exactly
+  elements 9, 10, 11, 12, 13 have one keyframe, and the child list opens with
+  9, 11, 12, 10, 13 — all five, before anything animated. That is unlikely to be
+  chance (5 of 24 in the first 5 slots), and it is a *file-visible* property.
+
+### Refuted as the ordering key, on this data
+
+* **first-keyframe time** — `back2eff1` starts at t=52 and paints *after*
+  `back2` (t=66);
+* **resting-keyframe time** — same pair, 56 against 80;
+* **declaration order and its reverse** — neither, obviously;
+* **the RATC child (sprite) order** — the group order does not ascend in it
+  (`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.