feat: Mantle mainnet custom gas fee

[jeremy-consensys]

Explanation

Mantle uses MNT as its native gas token, but the OP Stack oracle's getL1Fee(bytes) returns L1 data fees denominated in ETH. The existing OptimismLayer1GasFeeFlow would match Mantle (via the Gas API supported networks list) and use the ETH-denominated value directly, resulting in incorrect gas fee estimates.

This PR adds MantleLayer1GasFeeFlow, a new subclass of OracleLayer1GasFeeFlow that:

1. Calls getL1Fee(bytes) to get the L1 data fee (ETH-denominated)
2. Calls tokenRatio() on the same oracle contract (0x420...000F) to get the ETH/MNT exchange rate
3. Multiplies the L1 fee by tokenRatio to convert to MNT
4. Adds the operator fee (already in MNT) from getOperatorFee(uint256)

The flow is registered first in #getLayer1GasFeeFlows() so it matches Mantle transactions before OptimismLayer1GasFeeFlow can claim them.

Verified on-chain:

• tokenRatio() returns ~3020 (≈ ETH/MNT price ratio)
• getL1Fee returns ETH-denominated values confirmed by comparing oracle output against real transaction receipt l1Fee fields on mantlescan

Changes:

• New MantleLayer1GasFeeFlow.ts (~90 lines) extending OracleLayer1GasFeeFlow
• New MantleLayer1GasFeeFlow.test.ts (8 tests)
• Added MANTLE: '0x1388' to CHAIN_IDS in constants
• Registered MantleLayer1GasFeeFlow in TransactionController
• Changelog entry

References

• Mantle fee model (post-Arsia): L2 Execution Fee (EIP-1559) + L1 Data Fee (oracle, ETH-denominated) + Operator Fee (oracle, MNT-denominated)
• Oracle contract: 0x420000000000000000000000000000000000000F
• Pattern follows ScrollLayer1GasFeeFlow / OptimismLayer1GasFeeFlow

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Adds a new chain-specific L1 gas fee calculation path that changes fee estimation behavior for Mantle transactions; incorrect conversion or oracle call handling could misestimate fees on that network.

Overview
Adds a Mantle-specific Layer1GasFeeFlow that converts OP Stack oracle getL1Fee results from ETH-denominated values into MNT by multiplying by the on-chain tokenRatio(), then adds the (MNT-denominated) operator fee when gasUsed is available.

Registers this flow ahead of existing OP Stack/Scroll flows so Mantle transactions match the new logic first, adds CHAIN_IDS.MANTLE, includes a dedicated Jest test suite for conversion/error cases, and updates the transaction-controller changelog entry.

^{Written by Cursor Bugbot for commit 0e8a69b. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Possible double-counting of tokenRatio in L1 fee

High Severity

Mantle's official documentation states that getL1Fee already incorporates tokenRatio in its calculation (L1RollupFee = rollupDataGas × L1gasPrice × tokenRatio × scalar), returning a value denominated in MNT. Multiplying the result by tokenRatio again would inflate the fee by ~3020x. The PR states this targets "post-Arsia" behavior where getL1Fee returns ETH, but the Arsia upgrade was only confirmed for Mantle Sepolia (testnet, March 25 2026) — mainnet activation (chain ID 0x1388 targeted here) is unconfirmed. If deployed before Arsia reaches mainnet, gas estimates would be grossly overestimated.