[0xh3rman]

Fixes #1692.

An ENS name always resolved to its owner's Ethereum address, whatever EVM network the user sent on: EnsProvider ignored the chain and read addr(node). gemcoder.eth has 0xBA4D…0AC4 for Ethereum, 0xD8EB…88EA for Polygon and BNB Smart Chain, and nothing for Base; sending on Polygon, BNB Smart Chain or Base filled in 0xBA4D…. If that address is a smart wallet that doesn't exist on the other network, the funds land where the recipient can't use them.

1. Ethereum keeps addr(node) (coin type 60). Other EVM networks read addr(node, coinType) with the ENSIP-11 coin type 0x80000000 | chainId (alloy_ens::coin_type::evm_chain)
2. An empty record is not found, a 20-byte record is the address, anything else is an error. UnsupportedResolverProfile (a resolver without multicoin records) is not found
3. The owner's default EVM address (coin type 0x80000000) is applied by the resolver, per ENSIP-19, which tells clients not to add their own fallback. Live: gregskril.eth has only a default record and resolves on Base
4. The Universal Resolver call and its error mapping move into one private resolve helper
5. Product rule added under Names in docs/PRODUCT.md

Behavior change: a name with only an Ethereum record is now not found on other EVM networks. vitalik.eth and nick.eth have no Polygon, Base or default record, so they no longer resolve there.

Also: the SuiNS live test used alpha.sui, which is still registered but no longer has a target address; it now uses aftermath.sui.

Tests: unit tests use gemcoder.eth responses captured from mainnet (Polygon record, Base without one). The live name_resolver suite passes 15/15, including gemcoder.eth on Ethereum, Polygon and Base and gregskril.eth on Base.