Add canonical CAIP-2 registry address map for cross-chain discovery (EVM + non-EVM) #48

Today, scanners/watchtowers can rely on deterministic CREATE2 addresses across EVM chains.
For non-EVM chains (starting with Starknet), identical addresses are not feasible due to different address derivation.

This creates a bootstrap gap: before reading any agent registration files, clients need to know which registry contract address to query on each chain.

Proposal

Add a canonical machine-readable mapping file in this repo:

• registry-addresses.json (CAIP-2 keyed)
• short discovery doc (docs/registry-address-discovery.md)
• one README link to the map

Why

• Keeps current EVM behavior unchanged (CREATE2 parity remains)
• Adds explicit non-EVM discovery path
• Gives scanners one consistent bootstrap mechanism
• Format is extensible for future non-EVM networks without changing scanner logic

Initial scope

• EVM entries (mainnet + relevant testnets)
• Starknet entries (mainnet/testnet; placeholder/final values according to release process)

File shape (schema intent)

{
  "version": "1.0.0",
  "registries": {
    "identity": {
      "eip155:1": "0x...",
      "eip155:8453": "0x...",
      "eip155:11155111": "0x...",
      "eip155:84532": "0x...",
      "starknet:SN_MAIN": "<pending_review>",
      "starknet:SN_SEPOLIA": "<pending_review>"
    },
    "reputation": {
      "eip155:1": "0x...",
      "eip155:8453": "0x...",
      "eip155:11155111": "0x...",
      "eip155:84532": "0x...",
      "starknet:SN_MAIN": "<pending_review>",
      "starknet:SN_SEPOLIA": "<pending_review>"
    },
    "validation": {
      "eip155:1": "0x...",
      "eip155:8453": "0x...",
      "eip155:11155111": "0x...",
      "eip155:84532": "0x...",
      "starknet:SN_MAIN": "<pending_review>",
      "starknet:SN_SEPOLIA": "<pending_review>"
    }
  }
}

Canonical concrete values are in PR #49 / registry-addresses.json.

Notes

• Starknet CAIP-2 namespace is currently draft status (starknet:SN_MAIN, starknet:SN_SEPOLIA), so doc should include normalization guidance.
• This is a discovery/bootstrap artifact, not a protocol semantics change.
• Starknet addresses will be updated from <pending_review> after Leonard review + final redeployment process.