Recipient route guard duplicates parser rules with no contract test (drift risk)

[abalinda]

Follow-ups from the #2427 review (EIP-681 QR 404 fix) — none blocking that PR:

1. Guard/parser contract: couldBeRecipient (constants/routes.ts) is a hand-maintained synchronous superset of what parsePaymentURL accepts (USERNAME_PATTERN mirrors Signup.tsx, EVM/ENS shapes hardcoded). When a new recipient type is added, the parser accepts it but the guard 404s it first — the exact bug class fix: EIP-681 QR scans 404 — recipient guard rejects address@chainId #2427 fixed. Add a contract test asserting guard ⊇ parser, or extract one shared recipient-shape matcher.
2. Multi-@ split semantics differ: guard takes split('@')[0], parser takes last part as chain + rest as recipient. Both reject multi-@ inputs today, but they judge different strings — unify when doing (1).
3. Loose numeric chain parse: getChainDetails uses parseInt, so @42161garbage resolves as 42161 instead of erroring (validation/token.ts:80).
4. Soft-200 for invalid-chain recipient URLs: /0xADDR@garbage renders a 200 ErrorAlert (metadata says 'requesting funds', body errors). Consider notFound()/410 on INVALID_CHAIN if SEO noise ever materializes.