…ps and bucket-sharded inserts

Profiling block-assembly on a 558M-tx workload showed processNewBlockAnnouncement
spending 26-33 s wall-clock between block landing and BA being ready to mine on
top — the entirety of the "lost revenue" window between two blocks. CPU
profile attribution:

  - ~39 % runtime GC (scanObject/scanSpan/tryDeferToSpanScan/spanClass)
    driven by per-block fresh allocation of a ~614M-entry SplitSwissMap
    (transactionMap in CreateTransactionMap) and a fresh 4096-shard
    SplitTxInpointsMap (currentTxMap in resetSubtreeState)
  - ~17 % inside SyncedMap.SetIfNotExists RWMutex Lock/Unlock paths —
    real per-bucket contention with 375 workers
  - effective parallelism ~3.5 of 170 requested cores during the phase

This change attacks every measured source of slack across moveForwardBlock,
moveBackBlock, and reorgBlocks.

1. Pool the transactionMap (SplitSwissMap). Adds SplitSwissMap.Clear() that
   walks each per-bucket swiss.Map and calls its in-place Clear (which retains
   capacity by zeroing control + group arrays — no allocation). Adds a
   SubtreeProcessor.txMapPool field allocated lazily on the first
   CreateTransactionMap call and Clear()ed between blocks. The returned map
   is purely local to one moveForwardBlock and never escapes, so single-
   goroutine ownership is sufficient.

2. Double-buffer the currentTxMap (SplitTxInpointsMap). Adds a
   currentTxMapShadow field initialized at constructor time alongside the
   active map. resetSubtreeState now swaps the two pointers instead of
   allocating a fresh map; moveForwardBlock Clear()s the shadow after
   processCoinbaseUtxos succeeds. An internal deferred rollback inside
   moveForwardBlock swaps back if any post-reset step fails, preserving the
   captured originalCurrentTxMap pointer for the surrounding rollback code at
   the callers' three rollback sites (line 745 main-loop, lines 2760/2801
   reorg paths) — those sites continue to do
   stp.currentTxMap = originalCurrentTxMap as a harmless no-op.

3. Bucket-affinity sharding in parallelGetAndSetIfNotExists. Adds
   SplitTxInpointsMap.PutMultiBucketTxInpoints and BucketFor. The hot path
   now bucket-partitions input nodes (sequential pre-filter for coinbase +
   removeMap; sequential bucket count + slice fill) and dispatches one
   goroutine per non-empty bucket, capped by ProcessRemainderTxHashesConcurrency.
   Every destination bucket has exactly one writer — the per-bucket RWMutex
   is uncontended across workers, eliminating the 17 % mutex tax shown in
   profiling. The legacy per-node parallel scheme is retained as a fallback
   for the DiskTxMap path under legacyParallelGetAndSetIfNotExists. Bumps
   splitMapBuckets default from 4096 to 16384 via the new
   BlockAssembly.SplitMapBuckets setting; smaller per-bucket maps Clear
   faster and any residual contention drops further. Total memory unchanged.

4. processRemainderTxHashes Phase 1 — drop the literal 16-worker cap. The
   previous min(NumCPU, n/100, 16) hard-limited Phase 1 to 16 workers on a
   170-core pod when processing 30M-tx remainders. New
   min(NumCPU, max(2, n/1024)) chunks input in 1K blocks and scales with
   NumCPU. No new setting.

5. Block + mutex profiling. Adds top-level BlockProfileRate and
   MutexProfileFraction settings (default 0 = off; recommended on-cluster
   values 1000000 and 100). startProfilerAndMetrics now wires both into the
   Go runtime via SetBlockProfileRate / SetMutexProfileFraction. Necessary
   to quantify any residual wait time directly rather than infer from
   CPU-side mutex samples — both endpoints previously reported Count=0.

6. moveBackBlock parallel txInpoints insert. The previous serial
   addNode loops in moveBackBlockCreateNewSubtrees ran ~558M
   SetIfNotExists + AddSubtreeNode calls one at a time — a multi-minute
   serial path during reorgs. New helper addMoveBackBlockNodesToSubtrees
   splits the work into:

     Stage A — parallel chunked SetIfNotExists into currentTxMap, tracking
       per-node wasInserted using flatIndexToSubtreeNode for chunk-start
       translation. The map pointers alias the input subtreeMetaTxInpoints
       slice elements directly (no per-node allocation, same semantics as the
       original addNode call).
     Stage B — sequential subtree fill in canonical order calling
       addNodePreValidated (already existed in the codebase from the
       moveForward path). Duplicates from Stage A's wasInserted=false are
       skipped to match the original addNode's wasSet==false branch exactly.

   Falls back to the original serial path for DiskTxMap or sub-
   ParallelSetIfNotExistsThreshold inputs.

7. reorgBlocks rollback contract preservation. reorgBlocks captures
   originalCurrentTxMap once and expects the pointer to remain valid for the
   full multi-block loop so rollback can restore it. The double-buffer swap
   pattern breaks that contract across multiple iterations. Added a
   disableCurrentTxMapPool flag toggled by reorgBlocks for the duration of
   its call — resetSubtreeState then falls back to fresh allocation
   (original behaviour) and swapCurrentTxMapBack / clearCurrentTxMapShadow
   become no-ops. Single-goroutine, no synchronisation needed.

New unit tests cover:

  - SplitSwissMap.Clear empties every bucket and preserves usability for
    further inserts.
  - SplitTxInpointsMap.PutMultiBucketTxInpoints honours duplicate handling
    matching SetIfNotExists.
  - SplitTxInpointsMap.Clear preserves bucket structure.
  - Double-buffer swap-then-clear lifecycle: swap → shadow holds prior data,
    current is empty; swap-back restores original pointer identity;
    clear-shadow on commit leaves the shadow empty.
  - disableCurrentTxMapPool=true reduces swap-back and clear-shadow to
    no-ops, preserving the reorg rollback contract.

Existing tests in services/blockassembly/subtreeprocessor pass unchanged under
-race. No code outside blockassembly, settings, daemon changes.

Expected effect: moveForwardBlock wall-clock should drop from 26-33 s toward
under 10 s on a 500M-tx block at scale-2 settings; CreateTransactionMap from
~11 s toward 2-4 s; processing N remainder tx hashes from ~20 s toward 5-8 s.
GC-related funcs in CPU profiles should fall from cumulative ~39 % to single
digits; RWMutex Lock/Unlock under SyncedMap.SetIfNotExists from 17 % to near
zero.

Each per-bucket swiss.Map.Clear walks its own ctrl + group arrays and is
independent of every other bucket (separate RWMutex, separate storage). On
the pooled transactionMap (~614M slots, 1024 buckets, ~19 GB of key/value/
ctrl memory to zero), the previous serial loop was memory-bandwidth-bound and
synchronously held up the start of CreateTransactionMap on every block.

Dispatch min(NumCPU, nrOfBuckets) workers; each strides through its share of
bucket indices and Clear()s them. Stride pattern keeps the share even for
any bucket count and avoids a separate chunking step. Single-worker (or
single-bucket) path falls through to the previous loop to skip goroutine
overhead on tiny maps.

No correctness change; existing TestSplitSwissMap_ClearEmptiesAndPreservesUsability
continues to pass under -race.

…p on demand

Two issues surfaced in CI code review on #877:

1. addMoveBackBlockNodesToSubtrees Stage A worker advanced its flat
   (sIdx, i) cursor with a single if-step: i++ then, on overflow, sIdx++
   and i=0. If the next subtree slice was empty (or if several consecutive
   slices were empty), the very next iteration would access
   subtreesNodes[sIdx][0] with len==0 and panic. flatIndexToSubtreeNode
   already handled empty slices in its sequential count-down loop, but
   the worker's increment did not.

   Replace the single if with a for-loop that consumes any number of
   empty subtrees in a row. Added regression test
   TestFlatIndexToSubtreeNode_SkipsEmptySubtrees that walks a contrived
   subtreesNodes layout with three empty inner slices interleaved with
   non-empty ones and asserts the flat-to-(sIdx, i) mapping skips them.

2. CreateTransactionMap sized txMapPool lazily on the first block and
   never grew it afterwards. If the first observed block was modest in
   size (e.g. node starts during a low-traffic window) and later blocks
   were much larger, every subsequent block would silently trigger
   swiss.Map's internal auto-rehash inside the pool — allocating on the
   hot path and partially negating the pooling win that was the whole
   point of the change.

   Track txMapPoolCapacity on the SubtreeProcessor and adopt a high-
   water-mark policy:
     - nil pool: allocate at mapSize.
     - mapSize > capacity: reallocate at the new mapSize, record it as
       the new capacity. One alloc instead of an in-flight rehash.
     - else: Clear() in place (existing fast path).

   Reallocations only happen when block size grows beyond the recorded
   high-water mark; on steady-state larger blocks the pool is reused
   indefinitely. Added regression test TestTxMapPool_GrowsOnLargerBlock
   that asserts a smaller-or-equal request reuses the same *SplitSwissMap
   pointer (no reallocation) and a larger request returns a fresh
   pointer with updated capacity.

No behaviour change on the happy path. Existing tests under -race
remain green; staticcheck and go vet on the touched package clean.

…inside resetSubtreeState

resetSubtreeState performs the in-memory pool swap (currentTxMap ↔
currentTxMapShadow) before calling stp.newSubtree, which can fail (e.g.
subtreepkg.NewTreeByLeafCount returns ErrNotPowerOfTwo for a non-power-
of-two leaf count). Until now, that failure path left the swap committed:

  - moveForwardBlock's swap-back defer is registered AFTER the call to
    resetSubtreeState returns, so an early-return at line 4167 from a
    resetSubtreeState error never reaches the defer registration.
  - resetSubtreeState itself returned the error without any compensating
    action.

Net result: currentTxMap pointed to the empty shadow buffer, the prior
block's data was stranded in currentTxMapShadow, and the next
moveForwardBlock would capture the empty pointer as originalCurrentTxMap
— processRemainderTxHashes parent lookups then failed with "node X not
found in currentTxMap", cascading the failure across blocks.

Make resetSubtreeState atomic w.r.t. the swap. Track whether the swap
ran via a local swappedHere bool, and in a deferred guard call
stp.swapCurrentTxMapBack when err != nil && swappedHere. The other
branches (DiskTxMap, disableCurrentTxMapPool) don't swap and so don't
need rollback; the flag ensures we only roll back when we have to.

moveForwardBlock's own swap-back defer (registered after a successful
resetSubtreeState return) continues to handle failures from
processRemainderTransactionsAndDequeue, processCoinbaseUtxos, etc., so
each layer is responsible for the rollback of its own swap window.

Adds failure-injection test TestResetSubtreeState_RollsBackSwapOnNewSubtreeFailure
which sets currentItemsPerFile to 3 (non-power-of-two), seeds the pre-
swap map with a sentinel tx, calls resetSubtreeState(true), and asserts
that the returned error is surfaced AND that both the current and shadow
map pointers round-trip to their pre-call identity, with the sentinel
data still visible via currentTxMap. Pins the analogous-to-but-deeper-
than TestDoubleBuffer_SwapBackWipesPartialFailedWrite hazard.

Reported by @ordishs in #877.