Worker A's 0x80068910 and worker B's 0x800FA5D8 -- the latter carrying the region token
maspsx=moves in column 4, which is the first use of the new mode through the real merge
flow. The token survived sf3_merge intact and the full 549-region gate is GREEN with the
mode active, so worker B's oracle-driven mode is now load-bearing on a registered region.
That closes the loop on worker B's ASPSX result: it ran all five SDK assemblers as a
read-only oracle, found ASPSX does not fill delay slots, concluded maspsx is faithful and
that the fills come from GNU as in reorder mode, identified move->addu as the only real
gap, and the resulting mode is now matching a region in the tracked registry.
Christopher Williams
197a070f2f