[executor] encode_calldata returns anyhow::Result — violates library error convention

[obchain]

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

encode_calldata is a public library function that returns anyhow::Result<Bytes>. The established pattern in this codebase (PRs #28, #39, #41) requires thiserror-derived error enums on all library-crate public boundaries so the executor pipeline can distinguish recoverable errors (drop this opportunity, try next) from fatal errors (abort the process).

With anyhow::Result, a length-mismatch programmer error and an ABI encode failure produce identical opaque errors. The pipeline's error-routing logic cannot differentiate them without inspecting the string message, which is fragile.

Impact: Caller cannot distinguish recoverable from fatal errors. Future pipeline integration will either swallow all errors or abort on all errors, with no middle path. Inconsistent with the rest of the executor crate.

Fix:

1. Add thiserror to charon-executor/Cargo.toml dependencies.
2. Define #[derive(Debug, thiserror::Error)] #[non_exhaustive] pub enum BatcherError with variants ParamLengthMismatch { expected: usize, got: usize }, BatchTooLarge { len: usize, limit: usize }.
3. Change encode_calldata return type to Result<Bytes, BatcherError>.

Refs #45

[obchain]

Resolved on feat/20-multi-liq-batcher in 7080206. Added BatcherError (ParamLengthMismatch, BatchTooLarge, UnsupportedChain, AbiEncodeError) via thiserror; Batcher::plan and Batcher::encode_calldata now return Result<_, BatcherError>. anyhow is no longer on the public batcher surface.