fix(executor): wait for chain head advance between setup and test steps

[qu0b]

Summary

When running multi-block EEST fixtures (e.g., BAL scenario benchmarks), the executor runs setup and test steps sequentially. The setup step deploys contracts via engine_newPayload + engine_forkchoiceUpdated, and the test step immediately sends the benchmark block.

Problem: The test block's engine_newPayload returns SYNCING because the node hasn't committed the setup block as the canonical head yet. The engine_forkchoiceUpdated from the setup step returns VALID, but the internal state update is asynchronous — the chain head hasn't actually advanced when the next engine_newPayload arrives milliseconds later.

Fix: After the setup step completes successfully and before the test step begins, poll eth_blockNumber until the chain head advances beyond the pre-setup block number. This ensures the node has fully committed the setup block before receiving the test block.

• Polls every 200ms with a 30s timeout
• Falls back to a 500ms sleep if no baseline block info is available
• Non-blocking: logs a warning on timeout but doesn't fail the test (the existing retry_new_payloads_syncing_state mechanism can still recover)

Context

This is needed for EEST fixtures with setup+execution blocks, such as the BAL scenario benchmarks which test:

• Parallel execution (serial keccak chains)
• State root computation (disjoint SSTOREs)
• Cold storage prefetching (SLOAD linked-list chains)
• Deploy-then-interact (cross-tx code dependencies)
• Mixed dependency graphs (partial-order parallel scheduling)

These tests deploy contracts in a setup block and benchmark calls to them in the execution block. Without this fix, all multi-block tests fail with SYNCING.

Test plan

• Compiles successfully
• Run multi-block EEST BAL fixtures and verify setup blocks are committed before test blocks execute
• Verify single-block fixtures (no setup step) are unaffected
• Verify the wait doesn't add latency when chain head advances immediately

🤖 Generated with Claude Code

[qu0b]

Closing — the multi-block SYNCING issue was caused by genesis hash mismatch between EELS and geth, not by missing chain head synchronization. With the genesis fixes in jochem-brouwer/execution-specs#3 and fselmo/go-ethereum#1, all 44 BAL scenario tests (including multi-block deploy_then_interact) pass on upstream benchmarkoor without this change.