LGTM — the chunking pattern correctly mirrors stores/utxo/aerospike/longest_chain.go:MarkTransactionsOnLongestChain, the defensive clamps are a small improvement over the reference, and the loop-variable capture / non-overlapping slice access are race-free. A few notes before / after merge:

TestSyncManager_createUtxos_ChunkFailureCancelsSiblings is potentially flaky

The test is the only one that exercises the if mergeCtx.Err() != nil { return mergeCtx.Err() } short-circuit. With totalTxs=16, batchSize=4, routines=2, each worker performs exactly 2 iterations, and the .Once() chain orders exp1 → exp2 → exp3 in mock-match order, not worker order. Two scheduler interleavings are legal:

• Path A (test intent). Worker A iter 1 → exp1; Worker B iter 1 → exp2 (blocks); Worker A iter 2 → exp3 (fails, cancels); Worker B unblocks; Worker B iter 2 short-circuits. Removing the short-circuit fires exp4 → failureCount == 2 → test fails. ✅
• Path B (also legal). Worker A iter 1 → exp1; Worker A iter 2 → exp2 (blocks); Worker B iter 1 → exp3 (fails, cancels); Worker A iter 2 unblocks → returns nil; A done (no iter 3), B done. Neither worker has another iteration left to short-circuit. Removing the short-circuit makes no observable difference; the test passes regardless.

Under Path B the test green-lights a stripped implementation. Suggest either bumping totalTxs so both workers have ≥ 2 post-trigger iterations, or constraining the call order with an explicit handoff (e.g. atomic counter pinning the first call to a specific worker via the captured chunk identity).

Manual production validation still unchecked

The last item in the test plan — resume mainnet sync on bsva-ovh-teranode-eu-3 at block 755880 — is the only check that actually proves the connection-pool exhaustion is resolved. With default settings (MaxMinedRoutines=128, ConnectionQueueSize=16 per node per the PR description) the worker count still exceeds the per-node connection pool — the fix relies on Aerospike sharding spreading the writes across nodes. If shard skew is high on 755880, the same symptom could recur. Worth gating merge on completing that run.

Minor — discarded return map

SetMinedMulti returns map[chainhash.Hash][]uint32 of prior BlockIDs. Both pre- and post-PR code discards it, so no regression — but worth a sentence in the comment block on why the legacy netsync path is fine without prior-block-ID tracking, or a TODO if it should aggregate across chunks later.

Minor — settings doc drift

settings/utxostore_settings.go:49 still describes MaxMinedRoutines as "Block with 10,000 transactions split across 128 parallel workers (approximately 78 transactions per worker)." That math reflects the SafeSetLimit topology in model/update-tx-mined.go, not the worker-range topology now used here and in longest_chain.go. Two patterns coexist with one shared setting key — fine, but a follow-up to align the docs would help operators tune it.

Nit — symmetry with longest_chain.go

The batchSize < 1 and numWorkers < 1 clamps added here would also protect longest_chain.go:51-53 from misconfiguration. Optional follow-up.