phase11: merge 23 — 540 bodies / 549 regions, maspsx=moves verified through the merge

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.

config/regions.tsv

@@ -246,6 +246,7 @@
 0x800681E0	0x8006821C	src/func_800681E0.c
 0x800683B0	0x800683E4	src/func_800683B0.c
 0x80068470	0x8006848C	src/func_80068470.c
+0x80068910	0x800689DC	src/func_80068910.c
 0x80068D54	0x80068D78	src/func_80068D54.c
 0x80068F40	0x80068F6C	src/func_80068F40.c
 0x80068F6C	0x80068F98	src/func_80068F6C.c
@@ -485,6 +486,7 @@
 0x800F8FE4	0x800F8FF8	src/func_800F8FE4.c	maspsx=off
 0x800F8FF8	0x800F9008	src/func_800F8FF8.c
 0x800F9344	0x800F9380	src/func_800F9344.c
+0x800FA5D8	0x800FA65C	src/func_800FA5D8.c	maspsx=moves
 0x800FA960	0x800FA980	src/func_800FA960.c
 0x800FB13C	0x800FB1BC	src/func_800FB13C.c
 0x800FB5D4	0x800FB5DC	src/func_800FB5D4.c