Handle mainnet USDT allowance reset in Permit2 flows

Context

Permit2 flows read the ERC-20 allowance granted to the Permit2 contract. When the allowance is below the required amount, Monarch currently calls approve(Permit2, maxUint256).

Canonical Ethereum mainnet USDT is unusual: it rejects changing an allowance directly from one non-zero value to another. The allowance must first be reset to zero. Its revert has no reason data, so wallets such as Rabby may only show Simulation Failed (#-39000). This is user-state-dependent: users with zero or sufficient/unlimited allowance will not reproduce it.

Required behavior

Special-case canonical mainnet USDT using chain ID + token address, not symbol alone:

• allowance >= required: continue without approval
• allowance == 0: approve Permit2 for maxUint256, then continue
• 0 < allowance < required: approve Permit2 for 0, wait for confirmation, approve Permit2 for maxUint256, wait for confirmation, then continue the Permit2 flow
• Reflect both approval transactions in transaction tracking and preserve the existing behavior for every other token

Also use >= rather than > when checking whether the current allowance is sufficient, so an exact allowance does not trigger an unnecessary USDT reapproval.

Mainnet USDT: 0xdAC17F958D2ee523a2206206994597C13D831ec7
Permit2: 0x000000000022D473030F116dDEE9F6B43aC78BA3

Locate the TypeScript Permit2 allowance and approval flow, including transaction tracking, and start by tracing how insufficient allowances are handled. Verify the canonical mainnet USDT condition by chain ID and address, preserve behavior for other tokens, and confirm that exact, zero, and intermediate allowances produce the required approval sequence and tracked transactions.