feat(mcp): cap MCP batch tool at MAX_BATCH_OPERATIONS (PRJ-22)

- enforce the same 100-operation cap the HTTP /batch endpoint enforces;
  over-cap \x60calls\x60 reject with a structured INVALID_INPUT (retryable:
  false, matching CallError::invalid_input) before any dispatch
- hoist MAX_BATCH_OPERATIONS to gateway/mod.rs and reuse it in routes,
  to_openapi (removing a pre-existing duplicate literal), and to_mcp
- state the limit in the batch tool description and add maxItems to the
  input schema (doc previously advertised no limit)
- GatewayDispatch gains a per-instance invoke_count spy accessor so the
  over-cap test proves zero dispatches (process-global counters raced
  under the parallel test runner)
- tests: over-cap -> INVALID_INPUT + invoke_count()==0; at-cap -> 100
  results + invoke_count()==100

verification: scripts/verify.sh (352 passed) and scripts/verify.sh
--all-features (468 passed); cargo clippy --all-targets -D warnings and
cargo fmt --check clean

src/gateway/mod.rs

@@ -5,3 +5,10 @@ pub(crate) mod schema_cache;
 
 pub use dispatch::GatewayDispatch;
 pub use routes::CallRequest;
+
+/// The maximum number of operations accepted in a single batch,
+/// enforced identically by the HTTP `POST /batch` endpoint, the
+/// `to_openapi` gateway-spec projection, and the MCP `batch` tool
+/// (review-002 PRJ-22). One shared constant so the surfaces cannot
+/// drift.
+pub const MAX_BATCH_OPERATIONS: usize = 100;