688851122d
The screen object holds a SECOND list of its elements, a reordering built at load time, and that list is the paint order. It is 24 pointers at +0x30, each the +0x00 field of one of the 48-byte element records, so both arrays hold the same objects in different orders. Checked against the draw capture rather than asserted: the seven elements the capture can name sit at child slots 0, 6, 7, 13, 16, 17, 22 — strictly ascending, in exactly the captured submission order. It also resolves the one sub-order no static field could explain, the pair that decodes to the same 1133x280: slot 6 is element 20 and slot 7 is element 19, so they paint 20-then-19, DESCENDING in declaration terms. And the kind=0x4 repeat instances sit immediately after their template, where the declaration table interleaves them. Stated as unsolved, because the port cannot read a runtime array: deriving this order from the bundle. The order is clearly structured rather than arbitrary — elements sharing a sprite are adjacent and the full-screen effects lead — so it is worth attacking, but it is not attacked here.