Genesis sync fails at first block after NUMS activation (mainnet 941,223)

[technohippi3]

Syncing subspaces at 744e75a7625f98dbe5e3a484f962769e506c5381
from genesis on mainnet fails immediately after NUMS activation. The node
indexes through height 941,222, then fails to connect block 941,223 because
the NUMS store's tip is still 941,220. spaced exits and restart-loops at the
same point.

Applying the checkpoint embedded in the same revision (height 959,292,
SHA-256 verified) bypasses the transition and syncs normally to tip.

The relevant heights are:

COMMIT_BLOCK_INTERVAL = 36
NUMS_MAINNET genesis  = 941222

941220 = last commit boundary before activation
941222 = NUMS genesis; not a commit boundary
941223 = first height where can_scan_nums() is true; connection fails

Chain::load correctly begins the NUMS store at nums_genesis, and scanning
is gated:

pub fn can_scan_nums(&self, height: u32) -> bool {
    height > self.nums_genesis.height
}

However, maybe_commit commits both stores unconditionally at every Spaces
commit boundary, including those before NUMS activation:

self.db.sp.state.commit(checkpoint, spaces_batch)?;
self.db.num.state.commit(checkpoint, ptrs_batch)?;

This moves the NUMS tip backward from its correct genesis anchor to the
pre-activation Spaces checkpoints, ending at 941,220. Heights 941,221 and
941,222 advance only the Spaces tip because can_scan_nums is false. At
941,223, Client::verify_block_connected checks NUMS connectivity for the
first time and reports:

Could not connect block=<941223 hash>, height=941223 to checkpoint
[block=<941220 hash>, height=941220]

A possible fix is to gate the NUMS commit just as scanning is gated:

if self.can_scan_nums(checkpoint.height) {
    self.db.num.state.commit(checkpoint, ptrs_batch)?;
}

Reproduction:

1. Build spaced at 744e75a.
2. Sync mainnet from genesis against an unpruned Bitcoin RPC.
3. Observe the failure at 941,223 and subsequent restart loop.

We retained logs and a local rollback database, but the database contains no
additional evidence needed for this report and will not be uploaded. This
appears to be a fresh-sync transition bug rather than a consensus issue.