Feature: support Permit2 approvals inside MiniPay mini apps

## What

MiniPay mini apps should support Permit2-style approvals/signatures for ERC20 token spending, or document the current limitation clearly if Permit2 is intentionally unsupported.

Today, mini apps that need to swap ERC20 tokens have to ask the user to sign one `approve()` transaction per token before the actual swap transaction. This creates a poor UX for wallet-native flows where the app may need to spend from multiple supported tokens.

## Why it matters

MiniPay mini apps are commonly used for simple, mobile-first payment and swap flows. For these use cases, reducing transaction prompts is critical.

A common flow is:

1. User wants to buy a target token, e.g. COPm
2. The mini app detects balances across supported tokens, e.g. USDC, USDT, ETH/WETH
3. The app selects the token or tokens to spend
4. The user expects a simple "buy" experience

Without Permit2 or an equivalent batched approval/signature flow, the user may need to sign:

- approve USDC
- approve USDT
- approve WETH
- swap transaction

That can turn a simple swap into multiple wallet prompts, which is especially painful on mobile.

## Concrete example

We are building a MiniPay mini app that lets users buy COPm using tokens already in their wallet.

Supported tokens:

- USDC
- USDT
- USDm

The intended UX is:

1. User opens the mini app
2. User orders which tokens they prefer to spend first
3. User approves capped allowances, e.g. up to $450 per token
4. Later, when buying COPm, the user only signs the swap transaction

For a first version, we can work around this with normal ERC20 `approve()` calls per token. But if MiniPay supported Permit2, we could offer a much cleaner flow with fewer prompts and better user retention.

## Suggested resolution

Either of:

1. Add support for Permit2 signatures inside MiniPay mini apps, including any required typed-data signing methods needed by Permit2.

2. Document the recommended approval pattern for MiniPay mini apps that need ERC20 swaps:
- whether Permit2 is supported
- which signing methods are supported
- whether `eth_signTypedData_v4` works reliably
- whether there are token or chain-specific limitations
- recommended UX for capped approvals

3. If Permit2 is not planned, consider an official MiniPay-native alternative for approving multiple token spends with fewer user prompts.

## Reproduction / validation request

A minimal validation would be:

1. Open a MiniPay mini app on Celo
2. Connect the MiniPay wallet provider
3. Attempt a Permit2 approval/signature flow for an ERC20 token
4. Verify whether MiniPay supports the required signing method and whether the resulting Permit2 allowance can be consumed by a swap router

Expected outcome:

- MiniPay either supports Permit2 end-to-end, or
- MiniPay returns a clear unsupported-method error, and the docs explain the recommended fallback

Start by opening a MiniPay mini app on Celo and testing the MiniPay wallet provider with a Permit2 ERC20 flow. Check whether eth_signTypedData_v4 works and whether the resulting allowance can be consumed by a swap router; done means either end-to-end support or a clear unsupported-method result and documented fallback.

Written by the indexing model from the issue text.