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

[akundaz]

What is the purpose of this pool change atomic?

[julio4]

It lets the continuous loop detect pool changes without awaiting pool events (i.e. avoiding async overhead in the hot path). It coalesces all pool events into a single 'pool changed' signal, which also lets the loop skip useless iterations (if the pool hasn't changed, we can't produce a better candidate)

[avalonche]

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

[akundaz]

Shouldn't you run most of this (creating a new candidate) in a blocking task and then await it in each loop iteration?

[akundaz]

Are you not able to make this function async and race against this token?

[akundaz]

You already create a SharedBest up in run_continuous_flashblocks so you should use that one