The previous implementation looped per-tx and called PreviousOutputsDecorate
sequentially, which on legacy sync forced one OutpointBatcherDurationMillis
(default 10 ms, 5 ms on prod) flush per transaction. Each per-tx call only
queued ~2 inputs - far below OutpointBatcherSize (100/4096) - so the batcher
always waited the full duration before firing.

Observed on mainnet legacy sync at height ~381.5k:

  2856 tx  extendTx 14.34s
  2820 tx  extendTx 13.84s
  2076 tx  extendTx 11.18s
  1620 tx  extendTx  8.31s
   997 tx  extendTx  5.39s

Wall time tracked 5 ms x N_tx almost exactly, confirming the per-tx timer
floor as the bottleneck. CPU profile + goroutine dump showed exactly one
PreviousOutputsDecorate active and zero sendOutpointBatch workers running
during the wait - the aerospike batcher pool sat idle while the loop drained
one tx at a time.

Flatten every input across every tx into a single Put loop so the batcher
fills by size for the bulk of the work, with at most one timer flush for the
tail. Channel semantics are unchanged: each errChan is buffered cap 1 and
sendErrorAndClose is non-blocking, so returning on first error never blocks
in-flight workers.

Expected: extendTransactions for a 2856-tx block drops from ~14 s to
~10-50 ms.

The SQL store already implements this shape with
BatchPreviousOutputsDecorateConcurrency + chunked parallel; this brings the
aerospike store in line.

Replace the prior flatten-into-one-Put-loop approach with the simpler fix:
wrap the existing per-tx PreviousOutputsDecorate calls in an errgroup so all
of them push into the shared outpoint batcher concurrently. The batcher fills
by size from concurrent producers instead of idling at its per-tx duration
timer waiting for ~2 inputs to accumulate.

Same wall-time effect as the flatten variant, but the function body shrinks
back to a few lines and we stop having two near-identical loops in the
package (PreviousOutputsDecorate already owns the Put/drain logic).

Follow-up to review feedback on the prior commit; supersedes that approach.

BatchPreviousOutputsDecorate previously had no direct test in the aerospike
package - the prior implementation was a per-tx serial loop that delegated
straight to PreviousOutputsDecorate, so coverage on that single-tx path was
treated as sufficient. After switching to per-tx fan-out via errgroup, the
function now runs concurrent producers against the shared outpoint batcher,
which is exactly the path that was untested.

Add an aerospike_BatchPreviousOutputsDecorate subtest under TestAerospike
covering:

- Multiple child txs decorated in one call - asserts every input across every
  child is populated with the correct satoshis / locking script.
- Shared parent across children - same parent vout referenced by two children
  exercises the batcher's dedup of the underlying aerospike fetch even though
  goroutines race to request it.
- Empty / nil tx slice - no-op.
- Already-decorated input preserved - PreviousTxScript != nil inputs must not
  be overwritten (the early-skip in PreviousOutputsDecorate is what stops
  Phase 1's txMap work from being clobbered by Phase 2 in the legacy caller).

Runs under -race so any data-race introduced by the goroutine fan-out into
the per-input slot writes would be caught here.

Cap the per-tx errgroup at UtxoStore.OutpointBatcherSize (default 100, 4096
on prod overrides). The unbounded version was fine in practice - producers
spend most of their time parked on errChan receives, and the real ceiling
on aerospike round-trips is BatcherMaxConcurrent - but bounding the
goroutine count:

- Keeps memory predictable on pathologically large blocks (a 20k-tx block
  would otherwise spawn 20k goroutines, ~160 MB of stack at minimum, plus
  per-input channel allocations).
- Mirrors the Phase 1 errgroup bound in the legacy caller
  (services/legacy/netsync/handle_block.go:980), so Phase 2 no longer
  silently 20x's the producer-side parallelism of Phase 1.
- Matches the codebase pattern of bounding every errgroup that fans out
  per-tx or per-record work.

Throughput is unchanged: the bound is well above the BatcherMaxConcurrent
ceiling that actually gates aerospike batch throughput, and the upstream
batcher fills by size as soon as a few hundred producers have pushed.

Addresses review feedback on PR bsv-blockchain#893.