feat: continuous-build mode

[julio4]

📝 Summary

Adds a continuous flashblock building mode (under --flashblocks.continuous-build flag) that pre-seals candidates between scheduler triggers, so the best block is ready for instant publish when the timer fires.

Built on top of #438

How it works

1. Fallback block built as usual
2. Per flashblock interval, a blocking task runs a candidate loop:
   • Empty candidate sealed first (builder txs only) to guarantees a publishable result even if the scheduler fires immediately or the first candidate takes too much time to build
   • Pool candidates built continuously: clone base state → execute pool txs → add bottom builder txs → seal (state root) → keep if better than current best (by cumulative_gas_used)
   • Loop sleeps with exponential backoff when pool hasn't changed (driven by pool_change_epoch from a pool event listener)
   • When fb_cancel fires (scheduler trigger), the loop exits and returns the best candidate
3. Publish: the async orchestrator receives the pre-sealed result and publishes instantly via WS + payload channels
4. Spawn next: new blocking task starts immediately for the next interval

Details

• Gas limiter isolation: AddressGasLimiter wraps Arc<DashMap>, new snapshot()/restore() methods deep-copy the token buckets so each candidate starts with the same gas budget
• Pool change detection: A dedicated task listens to Pending and Replaced pool events, incrementing an AtomicU64 epoch. The candidate loop skips rebuilds when the epoch hasn't changed
• State reconstruction: Each blocking task reconstructs State<DB> from (CacheState, TransitionState) + state_by_block_hash since State isn't Send. build_block is designed to leave transition_state intact (saves/restores it internally)
• BestCandidate struct: All best-candidate state (cache, transitions, info, committed txs, sealed payload) grouped in a single struct, all updates are structurally enforced to be in same lockstep
• publish_and_spawn_next function: returns FlashblockAction::Continue { fb_span, build_rx, build_start } or Exit
• reserve_builder_tx_budget helper: Shared between sequential and continuous paths, adjusts gas/DA/uncompressed limits for bottom-of-block builder txs
• next_after_seal: Shared between sequential and continuous paths, encapsulates the DA/gas limit advancement for the next flashblock
• New metrics: continuous_build_duration, candidate_staleness, continuous_candidates_evaluated, continuous_candidates_improved

[avalonche]

why "better" is cumulative_gas_used instead of priority fee tips?

[julio4]

my intuition is that the candidate know how to order to i.e. maximize prio fee; but the outer candidate loop only try to maximize filling blocks. But there may be cases where best candidate is selected when we had a better one in terms of fees

[avalonche]

what if a tx comes in with high fees during flashblock block building, txs with high gas usage would be prioritized over the high fee tx no? I think we should always use priority fee as the metric as a better block

[akundaz]

What is the purpose of this pool change atomic?

[avalonche]

did you push your changes correctly? don't see code changes for comments