perf(node): pool aggregation prep vectors to cut GC pressure (#309)

[mananuf]

Summary

Adds sync.Pool reuse + capacity hints for the four prep slices used per data root in aggregateFromSnapshot (childProofs, rawPubkeys, rawSigs, rawIDs). Reduces young-gen GC pressure during the long-running FFI window — the suspected dominant source of gean's p99 tail above 1 s. Closes #309.

Why

Pre-PR: each iteration allocated 4 slices nil-initialised, grew them via append doubling, then discarded. At 5-20 data roots per pass, that's 20-80 allocations per pass × every interval-2 tick. The 400 ms FFI window is a generous opening for the runtime to schedule a 10-30 ms STW GC pause inside.

ethlambda pays nothing equivalent — Rust ownership, stack-allocated buffers dropped at scope exit (ethlambda/crates/blockchain/src/aggregation.rs:238 uses Vec::with_capacity).

What changed

New: node/aggregation_pool.go (+35 LOC)

Four sync.Pools, one per prep slice type, with first-fit capacity hints (8 children, 32 raw sigs). Typed get*Buf/put*Buf wrappers identical in shape to the existing xmss/proof_pool.go pattern. Put resets length to 0 preserving capacity.

Modified: node/store_aggregate.go (+116 / -109 LOC, net +7)

Refactor of aggregateFromSnapshot's per-data-root loop:

• Wraps loop body in func(){}() so defer pool-Put fires per iteration (not per function-return — the latter would defeat reuse).
• Replaces continue with return inside the anonymous func.
• Slice access via *bufPtr; appends via *bufPtr = append(*bufPtr, x).
• Capacity hint added to allIDs (was 0, now rawIDs + covered size).

Secondary win

defer xmss.FreeSignature(parsed) inside the inner sig loop now fires per data root rather than accumulating across the whole pass to function return. Tighter C-side handle lifetime; previously all parsed sig handles from all data roots in a pass leaked until aggregateFromSnapshot returned.

Behavior change

None. Same FFI calls in the same order, same store mutations (via *AggregationMutations from #307), same broadcast set. Only the lifetime of internal scratch slices and one C-handle defer batch changes — both shorter, both correct.

Expected impact

Per the gean-vs-ethlambda analysis: 20-40 ms p50 recovery, more on p99 (GC pauses are tail-dominant). Real numbers come from #305's phase-attribution histograms post-merge — if prep isn't where the gap lives, this PR's measured impact will be small and we'd refocus on post or commit.

Spec compliance

Zero impact. No spec-mapped function or container modified.

Test plan

• go build ./... clean
• go test -count=1 ./node/... green
• Post-merge: lean_aggregation_prep_time_seconds p99 should drop measurably vs the post-perf(node): instrument interval-2 aggregation phases for attribution (#305) #306 baseline; rate of Go GC pauses (via Go runtime metrics) should decline

Lean-review

• dead-code: N/A
• premature-abstraction: 4 pools, 8 helpers — sized to current need; no speculative pool surface
• defensive-bloat: N/A
• duplicates-existing-util: ✅ followed existing xmss/proof_pool.go pattern; no parallel pool helper invented
• comment-bloat: header on aggregation_pool.go is 8 lines explaining the why + the existing-pattern cross-reference; earns its keep
• over-validated-boundary: N/A

Stack

Originally stacked on PR #308 (snapshot refactor), which has now merged into perf/instrument-aggregation-phases. Rebased trivially; this PR now diffs cleanly against perf/instrument-aggregation-phases head with just the one Phase C commit.