Add USDC EIP-2612 Permit documentation

[janmd07]

docs: add Arc Testnet USDC EIP-2612 permit guide

[osr21]

Verified the technical content directly against Arc Testnet — every claim is correct, including the one that's hardest to get right:

• Chain ID and address: eth_chainId returns 5042002, and USDC lives at the 0x3600…0000 predeploy. ✅
• The EIP-712 domain is exactly right, verified on-chain. name() returns "USDC", version() returns "2", and reconstructing the domain separator from this doc's exact values — 5-field EIP712Domain(string name,string version,uint256 chainId,address verifyingContract), no salt — reproduces the contract's DOMAIN_SEPARATOR() byte-for-byte (0x361191…c6b0). This is worth calling out because it's a real trap: Ethereum mainnet USDC uses name = "USD Coin", and I confirmed that value produces a different separator, so anyone porting mainnet permit code to Arc without this doc would sign permits that revert. ✅
• A nuance that makes this doc more valuable than it claims: the Arc USDC contract does not implement ERC-5267 eip712Domain() (the call reverts), so tooling can't discover the domain automatically — hardcoding name/version (or reading name()/version() at runtime, as tests/helpers/FiatToken.ts does in signPermit) is genuinely required.

Two content suggestions if this moves forward:

1. The domain/types block is defined twice (once standalone, once inline in signTypedData) — the second block can just reference the first, halving the snippet.
2. The doc stops at producing the signature. A closing step showing what to do with it would complete the flow — and per the repo's own test helper ABI, Arc's NativeFiatTokenV2_2 supports both permit overloads: the classic permit(owner, spender, value, deadline, v, r, s) and the bytes signature variant (which accepts EIP-1271 smart-contract signatures). The bytes overload is worth documenting since 4337/smart-account users can't produce v/r/s ECDSA signatures.

On placement, one honest flag for maintainers to weigh: this repo's docs/ is consistently node-operator scoped (installation, monitoring, running-an-arc-node, ADRs, profiling, tx-forwarding), and root-level .md files are meta docs only (README, CONTRIBUTING, SECURITY, CHANGELOG, BREAKING_CHANGES, ACCOUNTS). There's currently no dapp-developer content here — integration guides of this kind live on developers.circle.com. So while the content is accurate and useful, a root-level usdc-permit.md may be out of scope for this repo; if maintainers do want it in-repo, docs/ (or a pointer from ACCOUNTS.md, which already documents the predeploys) would fit the existing structure better.

[melekes]

nice 👍 although it should probably go into a separate dapp docs repo.