Simulate EIP-1271 orders at creation

[squadgazzz]

Problem

Same as #4355: orderbook accepts an EIP-1271 order if the signer contract's isValidSignature says yes. That single check is enough to let through Aave flashloan-style orders where the signature passes but the post-hook can never settle. We catch these later, after they're in an auction, wasting solver cycles.

A symmetric class (Euler-style) is too strict on signatures but would actually settle fine. Those are rejected today.

Fix

This PR is the successor to #4355, rebuilt on top of new-api-simulator-crate (@MartinquaXD's SettlementSimulator refactor). At order-creation time, we run the signature check and a full-order simulation concurrently, then combine the results.

Per chain, a mode config picks what to do with the combined result:

• disabled (default): same as today. Signature check only.
• shadow: both run, disagreements land in metrics and logs, behaviour unchanged.
• enforce: if signature passes but simulation fails, reject with HTTP 400 Eip1271SimulationFailed.

Infra errors (RPC, timeout, Tenderly) never reject in any mode. Signature-fail cases return the same InvalidEip1271Signature as before, regardless of the simulation result.

What changed vs #4355

• The adapter drives SettlementSimulator::new_simulation_builder() instead of the legacy OrderSimulator.
• parameters_from_app_data handles pre/post hooks, custom wrappers, and Aave flashloan configs uniformly from the user-signed app_data. The earlier prototype injected these manually.
• The wrapper path (WrapperConfig::Flashloan(...)) routes through the deployed FlashLoanRouter, so the validation-time simulation now reflects the real Aave flashloan flow end-to-end. The borrower-to-trader transfer concern raised in the Simulate EIP-1271 orders at creation #4355 review is handled by the user-signed pre-hook (deploy helper, fund from factory), which parameters_from_app_data includes automatically.
• orderbook::run passes the FlashLoanRouter deployment address to SettlementSimulator::new instead of Address::ZERO, which would otherwise silently no-op the wrapper call.

Rollout

Same as #4355. Land as disabled. Flip to shadow in prod to see the matrix on real traffic. Flip to enforce once we trust the sim.

Changes

• shared::order_validation: new Eip1271Simulating trait, Eip1271Simulator bundle (simulator + mode + timeout) threaded into OrderValidator. Validation runs signature + sim concurrently via tokio::join! with a per-call timeout, emits an eip1271_simulation_total{signature, simulation} Prometheus matrix, upgrades enforce-mode disagreements to ValidationError::SimulationFailed.
• orderbook::eip1271_simulation: OrderSimulatorAdapter driving SettlementSimulator::new_simulation_builder() + parameters_from_app_data.
• orderbook::run: wire the deployed FlashLoanRouter address.
• configs: Eip1271SimulationMode enum with disabled, shadow, enforce variants.

How to test

Unit tests in shared::order_validation cover the signature × simulation matrix, enforce-mode rejection, fail-open on infra errors, the eip1271_skip_creation_validation path, and the no-simulator-configured path. configs tests deserialize the three modes.

Local-node e2e in crates/e2e/tests/e2e/eip1271_creation_simulation.rs:

• Negative: a Safe-signed order whose app_data.protocol.wrappers points at a custom always-revert wrapper. With Eip1271SimulationMode::Enforce, the orderbook returns HTTP 400 Eip1271SimulationFailed.
• Positive: a Safe-signed order with empty app_data is accepted.

Forked-mainnet replay in crates/simulator/tests/aave_replay.rs (gated on MAINNET_RPC_URL, otherwise skipped).

A full e2e test against a forked node isn't viable: OrderValidator::partial_validate checks valid_to against SystemTime::now(), and any historical order's valid_to is in the past on a fresh test run, so the orderbook rejects with InsufficientValidTo before the simulation ever runs. These tests therefore bypass the validator and drive SettlementSimulator directly.

• Replay of a real Aave v3 debt-swap order pinned to the block right before settlement. Asserts the simulation succeeds.
• Same order with flashloan.amount rewritten past Aave's WETH liquidity. Asserts the simulation reverts with execution reverted. The eth_call goes to FlashLoanRouter, which forwards to AaveBorrower, which asks the Aave Pool for the loan. Aave is what reverts (insufficient liquidity), but the revert only reaches us because the router and borrower addresses are correctly wired. If the wrapper had no-op'd against Address::ZERO the simulation would have succeeded silently.