[r3.5] cmd/integration: collate state files incrementally in parallel stage_exec

[sudeepdino008]

Problem

integration stage_exec on the parallel execution path (EXEC3_PARALLEL=true) never triggers step collation, so every step stays in the DB. stepsInDB grows monotonically to the full run and chaindata balloons. A later offline finalize (seg retire → agg.BuildFiles) then has to build each step by scanning the whole DB — effectively O(n²).

The serial path collates implicitly during execution, keeping the DB small.

Observed on a mainnet run to step 260 (block 4,665,800):

	serial (3.4-style)	parallel (before fix)
[agg] building during exec	482	0
stepsInDB at end	~2	260
chaindata after exec	34 GB	220 GB
offline seg retire	fast	~37 min/step × 260 ≈ 6 days

Fix

Kick agg.BuildFilesInBackground(agg.EndTxNumMinimax() + agg.StepSize()) each commit in the stageExec loop — the same call the node executor makes in its CommitCycle (execution/execmodule/executor.go). The loop's existing PruneExecutionStage → PruneSmallBatches then reclaims the collated steps, so the DB stays small on the parallel path too (build alone collates; build + the existing prune shrinks).

The buildFilesInBackground gate does not depend on LockWorkersEditing, so the call is effective during offline execution.

Testing

Behavior fix in the integration tool (not easily unit-testable without a full historical exec). Verified by the measurements above: before, parallel stage_exec leaves 260 steps in the DB; the change makes it collate/prune incrementally like the serial path and the node.