[contracts] batchExecute missing from fork test suite — batch path has no Aave V3 fork coverage

[obchain]

Refs #53

File: contracts/test/CharonLiquidatorFork.t.sol (new file — absence of coverage)
Contract: contracts/src/CharonLiquidator.sol, batchExecute()

Problem:
PR #45 added batchExecute to CharonLiquidator. The fork test suite introduced in PR #53 only exercises executeLiquidation. batchExecute runs N flash loan callbacks in sequence, holds the reentrancy guard across all iterations, and calls executeOperation once per item. This is the highest-risk code path in the contract:

• N callbacks each sweep profit to the hot wallet (compounds issue [PR #37] p0-blocker: profit swept to hot-wallet owner, not cold wallet — violates CLAUDE.md safety invariant #120/[contracts] batchExecute multiplies hot-wallet profit sweep across N flashloan callbacks #205 N times).
• Reentrancy guard held across the entire batch means any callback reentrancy behaves differently than in single-liquidation mode.
• The 10-item ceiling (MAX_BATCH_SIZE) and its interaction with Aave V3's flashLoanSimple queue is unvalidated.

The unit tests in CharonLiquidator.t.sol cover ownership guard, empty array, and over-limit, but these do not use a real Aave pool. Fork coverage is the only way to validate that batchExecute actually completes multiple flashLoanSimple calls in sequence on the real Aave V3 BSC pool.

PRD clause: CLAUDE.md: 'Every liquidation transaction passes an eth_call simulation gate before broadcast.' The simulation gate validates the full tx including batches; if batches are never fork-tested, simulation gate validity is unknown.

Impact:
batchExecute is the primary production code path for multi-opportunity windows. It has been shipped in PR #45 without any fork-level validation that N sequential flash loans actually complete on BSC Aave V3.

Fix:
Add test_fork_batchExecute_twoMarkets() that calls batchExecute with a 2-item LiquidationParams array, mocking Venus and PCS per item, and asserts:

1. Both LiquidationExecuted events are emitted.
2. The reentrancy guard does not block the second callback.
3. Profit (once [PR #37] p0-blocker: profit swept to hot-wallet owner, not cold wallet — violates CLAUDE.md safety invariant #120 is fixed) routes to coldWallet for each item.

[obchain]

d3f4739