fix: skip parallel BAL path while Firehose traces

[sduchesneau]

Cause

Block 11856337 is the first Sepolia block that carries a block access list (BAL). It has 101 transactions, and sender 0x7609…5456 has three of them in a row: index 48 (nonce 75785), 49 (75786) and 50 (75787).

• validate_block_with_state decides it can use the parallel BAL path before it checks whether Firehose is tracing. It then starts the payload processor in BAL mode.
• In BAL mode, for blocks with 30 or more transactions, the payload processor recovers transaction signatures in parallel. It hands each transaction to execution as soon as it is ready, so they arrive out of block order (payload_processor/mod.rs:292).
• Our traced execution path (execute_and_trace_block) runs transactions one after another using handle.iter_transactions(), which drops the index. It ran them in whatever order they arrived.
• Tx 50 ran second, before txs 48 and 49, so it hit "nonce 75787 too high, expected 75785". received=1 in the log matches this: only one receipt had been produced when it failed.

The BAL from the public node has the correct nonce changes for this sender, so the block itself is valid. Our existing Amsterdam test didn't catch this because its blocks have fewer than 30 transactions, and those are still delivered in order.

Fix

At payload_validator.rs:615, don't use the parallel BAL path while Firehose tracing is on:
let parallel_bal_execution = ensure_ok!(self.bal_path_eligible(env.decoded_bal.as_deref())) &&
!reth_firehose::is_tracer_initialized();
With that, transactions arrive in block order, cache prewarming works from the transaction list, and the state root uses the hook from execution, which is how the traced path already ran before Amsterdam. I also extended firehose_live_tracing_amsterdam.rs with a block of 40 transfers from one sender, and it checks that the traced nonces come out as 0..39 in order.

Tests

passes updated local test