fix: prevent pendingBridgeFees underflow on truncated batch fees (DEC-820)

[clemsos]

Summary

• Per-message fees in handle() use integer division and truncate to 0 for small message.amount. The batch fee in claim() is computed off the aggregated claim amount, where floor(sum) >= sum(floor). When the gap is non-zero, pendingBridgeFees -= feeAmount underflows and reverts the claim.
• Tracks accumulated fees per (chainId, bridge) and bounds the claim-time subtraction with Math.min(accumulatedFeesByOrigin, batchFee). This also stops one origin from silently consuming another origin's accrued fees.
• Adds fee-truncation.hardhat.ts with three scenarios: (1) 1000 dust messages — claim panics under old code, succeeds with 0 fee under fix; (2) a dust origin's claim does not eat the OP origin's pending fees; (3) a normal claim still drains accumulated fees.

Detail

In handle():

uint256 feeAmount = (message.amount * origin.bridgeFee) / FRACTIONAL_BPS_DENOMINATOR; // can be 0
accumulatedFeesByOrigin[chainId][bridge] += feeAmount;
pendingBridgeFees += feeAmount;

In _claim():

uint256 batchFee = (amount * origin.bridgeFee) / FRACTIONAL_BPS_DENOMINATOR;
feeAmount = Math.min(accumulatedFeesByOrigin[chainId][bridge], batchFee);
accumulatedFeesByOrigin[chainId][bridge] -= feeAmount;
pendingBridgeFees -= feeAmount;

The processFailedHandler rescue path is unchanged — it skips fee processing on both sides and so does not need to touch the new mapping (consistent with the DEC-652 fix in #768).

Impact

• Old behavior: a sequence of dust messages on a quiet origin can DoS claim() for that origin until unrelated handle() activity refills pendingBridgeFees.
• New behavior: dust messages stay accounted for, and even the worst case (per-message fees all truncate to 0) cleanly results in a 0-fee claim instead of an arithmetic panic.

Deployment note

RelayPool is deployed by RelayPoolFactory.deployPool via new RelayPool(...) — it is not a proxy and not upgradeable. Already-deployed pools will not pick up this change; only newly deployed pools will. The existing pools should be redeployed if this fix needs to apply to them.

Test plan

• yarn hardhat test test/RelayPool/*.hardhat.ts — 86 passing, including the 3 new tests in fee-truncation.hardhat.ts
• yarn lint:contracts — 0 errors (warnings unchanged from main)
• Existing failed-hyperlane.hardhat.ts tests still pass, including the cross-origin fee preservation and normal claim path tests

🤖 Generated with Claude Code