[executor] selector test is self-referential — no canonical keccak256 pin for batchExecute

[obchain]

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

The selector test asserts:

assert_eq!(
    &bytes[..4],
    &ICharonBatch::batchExecuteCall::SELECTOR,
    "calldata selector drifted from batchExecute"
);

Both the left side (computed by encoding via ICharonBatch) and the right side (the constant from the same sol! block) come from the same alloy::sol! declaration. The test verifies internal consistency within Rust only. If the Solidity batchExecute function signature changes on-chain but the Rust sol! macro is not updated in lockstep, the test continues to pass while the deployed selector diverges.

Impact: The selector pin provides false assurance. The only way to detect Rust-vs-Solidity ABI drift using this test is if a human manually updates the sol! block — the test does not catch the case where neither side is updated after an on-chain change.

Fix: Add a hardcoded expected-selector constant:

const BATCH_EXECUTE_SELECTOR: [u8; 4] = [0xXX, 0xXX, 0xXX, 0xXX];
// keccak256("batchExecute((uint8,address,address,address,address,address,uint256,uint256)[])")[..4]

Assert against that constant instead of (or in addition to) the sol!-derived value.

Refs #45

[obchain]

Resolved on feat/20-multi-liq-batcher in 7080206. Selector test now computes keccak256 of the canonical Solidity signature "batchExecute((uint8,address,address,address,address,address,uint256,uint256)[])" via alloy::primitives::keccak256 and compares the first four bytes against the calldata prefix. A belt-and-braces assert against ICharonBatch::batchExecuteCall::SELECTOR catches alloy-side regressions; the externally-computed digest catches any joint drift of both the macro and the on-chain signature.