Stablecoin gas fees: allow users to pay transaction fees in ERC-20 stablecoins

## Summary

Enable end users to pay gas fees in supported ERC-20 stablecoins (e.g., USDC, USDT) instead of requiring them to hold native ETH, eliminating the largest onboarding friction for enterprise and fintech customers.

## Motivation

Today, every user of an ev-reth chain must acquire and hold native ETH to pay gas fees. This is a significant barrier for:

- **Enterprise customers** who want predictable, stable fee structures
- **End users** onboarded through fintech/payment apps who should never need to think about gas tokens
- **Compliance teams** who prefer USD-denominated cost accounting

Tempo (Stripe/Paradigm's payments-first L1, also built on Reth SDK) has validated this pattern: users pay fees in any supported stablecoin, and a protocol-level mechanism handles conversion. ev-reth's ADR-0003 already implements fee sponsorship (sponsor pays gas on behalf of user), but stablecoin gas goes further by removing the native token requirement entirely.

## Design considerations

### Option A: Fee AMM (Tempo's approach)
- Deploy an on-chain AMM that converts stablecoin fee payments to the native token at execution time
- The EVM handler deducts stablecoins from the user, swaps through the AMM, and burns/distributes native token equivalent
- Pro: Fully on-chain, transparent pricing
- Con: Requires AMM liquidity, adds execution complexity

### Option B: Sequencer-side conversion
- The sequencer (ev-node) accepts stablecoin-denominated fees off-chain
- Payload builder credits native gas from a system account and debits stablecoin balance
- Pro: Simpler, no AMM needed
- Con: Centralized pricing, trust assumption on sequencer

### Option C: Precompile-based fee deduction
- A system precompile at a fixed address handles stablecoin balance checks and deductions
- Custom EVM handler in `crates/ev-revm` overrides fee deduction to call the precompile
- Pro: Clean separation, composable
- Con: New precompile surface area

## Scope

1. Decide on conversion mechanism (AMM vs sequencer vs precompile)
2. Extend `EvEvmConfig` / custom EVM handler in `crates/ev-revm` to support non-native fee deduction
3. Define supported stablecoin registry (chainspec or system contract)
4. Modify receipt/RPC responses to indicate actual fee token used
5. Update gas price oracle / fee estimation RPCs to return stablecoin-denominated prices
6. Integration tests covering: stablecoin-only user paying gas, mixed native+stablecoin blocks, edge cases (insufficient stablecoin balance, price oracle failure)

## Prior art

- [Tempo: stablecoin gas fees](https://docs.tempo.xyz/learn/tempo/performance) -- Fee AMM approach, no native token
- [EIP-4337 Paymasters](https://eips.ethereum.org/EIPS/eip-4337) -- Account abstraction approach (higher overhead)
- [ADR-0003](docs/adr/ADR-0003-typed-transactions-sponsorship.md) -- ev-reth's existing fee sponsorship model (complementary, not replacement)

Inizia da docs/adr/ADR-0003-typed-transactions-sponsorship.md e dal gestore EVM personalizzato in crates/ev-revm. Determina innanzitutto se il design utilizza una AMM, una conversione lato sequencer o un precompile, quindi traccia EvEvmConfig e gli entry point per la stima delle fee e per receipt/RPC. Il lavoro è completato quando le stablecoin supportate possono pagare le fee, le risposte riportano il token delle fee e i test di integrazione coprono i casi di successo, misti, saldo insufficiente e errore dell’oracolo.

Scritto dal modello di indicizzazione a partire dal testo della issue.