refactor: record and drive shard splits from the parent shard controller

[mattisonchao]

Problem

runtime.InitiateSplit recorded a split with UpdateNamespaceStatus, which replaces the whole namespace blob. Its read-modify-write happens outside the CAS, so any shard controller that wrote its own shard in between lost that write:

coordinator: read namespace status ............................ store all shards
shard 7 controller:      elect leader, write shard 7 ^                      |
                                                     lost ------------------+

The split then kept writing the parent and both children from its own goroutine, racing the parent controller's elections on the same shard.

Change

Metadata.InitShardSplit — one operation that marks the parent and creates both children in a single update, with its preconditions checked inside the CAS. Only what the metadata layer cannot derive is passed in (reserved child ids, split point, the children's ensembles); the children's hash ranges and the rest of their metadata are built there, so a child cannot disagree with the parent it was split from.

Splitting — one round of splitting a shard, owned by the parent's shard controller the way Election already is: created from a Split action or resumed from persisted state at startup, held as currentSplitting, stopped with the controller. runtime.splitControllers and restartInProgressSplits are gone.

The coordinator keeps what needs the cluster-wide view — validation, ReserveShardIDs, ensemble placement — and dispatches the rest. The action is dispatched without the coordinator lock, since it is completed by the controller's event loop, whose other work (LeaderElected) calls back into the coordinator.

The split phases still run in SplitController on its own goroutine. They move onto the round in a follow-up, which is when the remaining split writes come into the loop.

Test plan

• go test ./coordinator/... -count=1 (oxiad)
• go test ./coordinator/ -run 'TestCoordinator_ShardSplit|TestCoordinator_AutoSplit' (tests) — 148s, all pass
• New InitShardSplit coverage: children partition the parent's range, parent keeps serving until complete, every precondition rejects and persists nothing, caller ensembles stay isolated
• make lint — could not run locally: golangci-lint is built with go1.26, config targets 1.27

Follow-ups

CompleteShardSplit / AbortShardSplit, then the phases move onto Splitting and the split's writes move into the controller's event loop.