The word at +0x08 of a T8aD header — which this project's decoder never read, taking width/height/tiles from +0x14 onward — is non-decreasing in the order the game paints a screen, on BOTH screens whose order has been measured: 20 of the title's 24 elements (the other four have no T8aD sprite) and 6 of the splash's 7. No inversion anywhere. On the splash it explains the whole permutation: the three _eff glows carry 0xa100 and their base logos 0xa110, so the glows paint first even though the declaration table interleaves them. This is the first FILE-DERIVABLE account of the paint order. Everything checked before failed — declaration order and its reverse, the placement region, the RATC child order, keyframe start and rest times, resting Y, the runtime record's fields, and every other build's table. Recorded as unsettled: the ties (two groups share a key and are painted in an order that is not declaration order), what the bits actually mean (the values look like flag words, and the two screens use different ranges), and the fact that two screens is two screens — a third permutation either promotes this to a rule or breaks it.