Two checks on last iteration's "sequential, not simultaneous" reading.
First, the phases really are disjoint. If glows and logos ever shared a
frame the claim would be wrong. Across all 235 captured frames the count
of frames containing both is ZERO, and the switch is a single clean
boundary -- f110-115 draw 1280x720 + 262x108 + 525x90, f116 onward
1280x720 + 243x86 + 499x72. Two sprites either side, no transition frame.
Second, and larger: a third of the bundle is never drawn. Entry 11
declares three logo/glow pairs and only two appear.
palogo_gamearts / _eff 95 / 22 frames
palogo_seta / _eff 95 / 22 frames
palogo_anima / _eff never
palogo_anima declares the SAME keyframe times as palogo_gamearts. Two
elements with byte-identical data, 95 frames and 0 frames in one run.
Reach: the capture covers frames 1-214, so this is "never in the window".
So a bundle is a palette, not a script. Its elements say what to draw and
for how long; which of them run, and when each starts, is decided outside
the placement data. That is the same conclusion the boot-order work
reached from the other end -- the driver is code, not data -- now with a
per-element measurement behind it.
For the port, concretely: compositing every element of a bundle does not
reproduce what the game shows over time. It is the right thing for a
static screen that settles, and it is not a timeline.
METHOD: two elements with identical data and different outcomes is the
strongest possible evidence that the decision is elsewhere.