fix(cctp-finalizer): pad receiveMessage gasLimit to avoid out-of-gas reverts

[ashwinrava]

Problem

During the 2026-08-19 ~15:30Z incident, sponsored-CCTP mints on Mainnet intermittently reverted out of gas and breached finalization SLAs:

• 0x9a98dba1 and 0x5b31a4f8 both reverted with gasUsed 509,046 of a 511,460 limit (99.5%).
• Successful retries of the same messages estimated 528,814 and used ~437,900.

processMintEvm submits mints through submitTransaction, which discards the simulated gasLimit and lets ethers re-estimate at send time with zero headroom (DEFAULT_GAS_LIMIT_MULTIPLIER = 1.0, and gasLimitMultiplier padding is a no-op when txn.gasLimit is undefined). receiveMessage gas usage on the SponsoredCCTPDstPeriphery is state-dependent, so a mint included after a sibling mint changed state can need ~20k more gas than estimated and dies at its limit.

Change

Scoped to the cctp-finalizer only — the shared submitTransaction helper and all other bots are unchanged:

• processMintEvm now simulates via TransactionClient.simulate and submits the simulated transaction, whose defined gasLimit lets the multiplier apply.
• Adds gasLimitMultiplier: 1.2 (511k estimate → ~614k limit, comfortably above the ~530k worst case observed; unused gas is refunded).
• Error semantics preserved: throws on simulation failure and on empty submit result, matching the previous submitTransaction behavior so caller retry/nack flow is unchanged.

Testing

• yarn eslint and tsc --noEmit clean.
• Replay of the failed 0x5b31a4f8 calldata via eth_call with a padded limit succeeds.

🤖 Generated with Claude Code