docs: document App Kit Arc Testnet chain id and capabilities

[kutluhaneth46]

Summary

Fixes #88.

Early App Kit releases left kit.bridge() / kit.send() Arc Testnet paths poorly documented. Current Circle docs support Arc Testnet for Send, Bridge, Swap (USDC/EURC/cirBTC), and Unified Balance with the case-sensitive chain id Arc_Testnet.

This PR adds an in-repo developer note so builders starting from arc-node get those answers without hunting external pages alone, and links it from the README documentation list.

Changes

• Add docs/app-kit-arc-testnet.md covering supported methods, Arc_Testnet / BridgeChain.Arc_Testnet, minimal bridge/send/swap examples, and practical adapter/kit-key notes
• Link the note from README.md

Sources

• https://docs.arc.io/app-kit
• https://docs.arc.io/app-kit/references/supported-blockchains
• https://docs.arc.io/app-kit/quickstarts/send-tokens-same-chain
• https://docs.arc.io/app-kit/swap

Test plan

• Claimed docs: Circle AppKit v1.5.x kit.bridge() and kit.send() have no documented Arc Testnet integration path — only kit.swap() / estimateSwap() are viable #88 before opening the PR
• Cross-checked capability table and chain id against current Circle App Kit docs
• Maintainer skim of links and wording

[osr21]

The new note is useful. I suggest adding two practical clarifications before merge because the capability table alone can be read as a guarantee that a route is currently executable:

1. Separate API capability from route/liquidity availability. getSupportedChains('swap') can say Arc is supported while a particular token direction still returns INPUT_UNSUPPORTED_ROUTE (331001) or ONCHAIN_SIMULATION_FAILED. Recommend telling callers to treat those as normal route-unavailable states, surface them clearly, and never replace a failed executable quote with a market-rate estimate.

2. Make the signing boundary explicit. The browser Viem/Ethers adapter path should keep signing in the connected wallet and does not need a backend private key. If a Circle Wallets/server-side example uses a developer-controlled key, that should be called out as a different custody model. In particular, a public API process should not hold a signer that can act against user-granted allowances.

A current Mainnet validation may be useful context (not a Testnet/App Kit claim): an immutable ownerless USDC/EURC wrapper at 0x6B5D...0e49 completed 0.10 USDC → 0.086869 EURC through official SwapRouter02 with direct recipient settlement and zero residual router allowance. That implementation deliberately fails closed when no executable quote exists; this is a useful invariant to mention alongside runtime chain discovery.

[kutluhaneth46]

Thanks @osr21 — applied both clarifications in ebb3712:

1. Capability vs route/liquidity: getSupportedChains is API capability only; treat INPUT_UNSUPPORTED_ROUTE (331001) / ONCHAIN_SIMULATION_FAILED as normal route-unavailable states and never substitute a market-rate estimate for a failed executable quote (fail closed).
2. Signing boundary: browser Viem/Ethers keeps signing in the connected wallet; Circle Wallets developer-controlled keys are a different custody model, and a public API process should not hold a signer that can act on user allowances.

[kutluhaneth46]

Replaced the cloud-agent SSH-signed commit (unknown_key) with a GitHub-verified commit (6e4e6b1) carrying the same docs clarifications. Signature check should be green on the next PR workflow run.