Include block number in logged Tenderly simulation command

[squadgazzz]

Description

The Tenderly simulation command logged during quote verification cannot be replayed as-is: Tenderly rejects it with Transaction index is not allowed when block number is pending. The verifier passed block: None to log_simulation_command, which leaves block_number null in the JSON body (Tenderly treats this as pending) while prepare_request still set transaction_index: -1, and that combination is invalid. On top of that, simulate_swap_with_solver did not pin .call() to a specific block, so the node picked "latest" at request time and the logged block could diverge from what was actually simulated.

Changes

• simulate_swap_with_solver now takes the block as a parameter and pins .call() to it. The caller (trade_verifier) snapshots current_block once and passes the same value to the simulator and to log_simulation_command, so the gas-price computation, the simulation, and the logged curl all reference identical chain state.
• log_simulation_command and prepare_request now require a BlockNo (no longer Option<BlockNo>), reflecting that every caller already supplies one and eliminating the pending-block edge case at the type level.

How to test

Existing tests. After deploy, copy the curl command from the quote-verification log and run it — Tenderly should return a simulation instead of the validation error, and the result should match the driver's simulation for that block.

[gemini-code-assist]

Code Review

This pull request updates the Tenderly simulation logging to include the current block number and modifies the request preparation to conditionally set the transaction index only when a block is specified, preventing rejections on pending blocks. No critical issues were found, and I have no feedback to provide.

[gemini-code-assist]

Code Review

This pull request updates the trade verifier and simulator to include block numbers in Tenderly simulation logs and swap simulations, ensuring that the transaction_index is only set when a block is specified. A high-severity race condition was identified in the trade verifier where the block number is fetched after an asynchronous simulation call, potentially leading to inconsistent logs if a new block is mined during the process. It is recommended to refactor the simulator API to return the block number used during simulation to ensure consistency.

[MartinquaXD]

LGTM