[executor] encode_calldata has no simulation gate — CLAUDE.md eth_call invariant violated

[obchain]

PR: #45 (feat/20-multi-liq-batcher)
File: crates/charon-executor/src/batcher.rs, encode_calldata

CLAUDE.md states: 'Every liquidation transaction passes an eth_call simulation gate before broadcast.' encode_calldata produces the ABI-encoded batchExecute(...) calldata but performs no simulation and has no structural constraint that forces the caller to simulate before broadcasting.

The PR description defers simulation wiring to 'a downstream caller (CLI pipeline, in a later PR).' There is no tracking issue for that downstream wiring, no assertion in encode_calldata's contract that the caller is obligated to simulate, and no doc comment linking to a required follow-up.

Impact: A caller that wires encode_calldata directly to Submitter — skipping Simulator — violates the CLAUDE.md hard invariant with no compile-time or runtime warning. The batch path is operationally different from the single-item path (which has sim wired in PR #41); inconsistent enforcement of the gate creates a regression risk when the batch path is wired in the CLI pipeline.

Fix:

1. Open a tracking issue for simulation of batch calldata before it is connected to TxBuilder/Submitter.
2. Add a /// # Safety doc comment to encode_calldata explicitly stating that callers MUST pass the returned bytes through Simulator::simulate() before signing and broadcasting, referencing the tracking issue number.
3. When the CLI pipeline is wired (the deferred PR), enforce that encode_calldata output goes through the same simulation path as single-item executeLiquidation calls.

Refs #45

[obchain]

Resolved on feat/20-multi-liq-batcher in 7080206. encode_calldata rustdoc now carries an explicit # Safety section: callers MUST pass the returned calldata through Simulator::simulate before broadcasting, per the CLAUDE.md eth_call-gate invariant. Downstream sim-wiring for the batch path is tracked in #298.