[Bug]: The CLI and the UI cannot target mainnet: no mainnet configuration exists

Component

Other

Priority

P1

What happened?

packages/cli/src/utils/constants.ts defines the complete set of environments the CLI accepts:

const DOTNS_ENVIRONMENT_IDS = ["paseo-v2", "previewnet", "devnet"] as const;

There is no mainnet, Polkadot or production Asset Hub entry, and grepping constants.ts for any of those names returns nothing. resolveDotnsEnvironmentId throws on anything outside the list: Unknown DotNS environment "mainnet". Use one of: paseo-v2, previewnet, devnet. So once mainnet is deployed there is no way to point the CLI at it, and every consumer path is blocked: registering,
resolving, setting content, and the browse client that drives its domain through this CLI.

packages/ui has the same gap, expressed differently. It carries no environment list; testnet identity is spread across module constants in src/lib/networks.ts: SUPPORTED_NETWORKS, DEFAULT_NETWORK_ID, TOKEN_UNIT, BLOCK_EXPLORER, SUPPORTED_NETWORKS.

Expected behavior

A mainnet configuration exists in both packages. The CLI gains an environment id with its RPC, contract addresses, explorer and gateway URLs, selectable through --env and DOTNS_ENV. The UI can represent more than one network, with the token symbol, explorer and gateway resolved from the selected network rather than from module constants.

Reproduction

dotns lookup owner-of game --env mainnet
# Error: Unknown DotNS environment "mainnet". Use one of: paseo-v2, previewnet, devnet

For the UI, there is no command to run: SUPPORTED_NETWORKS contains one chain id and DEFAULT_NETWORK_ID is that chain, so no code path can select another.

Additional context

The addresses for this entry do not exist until the mainnet deploy runs, so this is on the critical path immediately afterwards rather than something that can be prepared in advance.

That makes the ordering matter. If the entry is hand-transcribed like the existing ones, it inherits the problem in #221, where the paseo-v2 literals went stale after a chain reset and the same values are also stale in DEPLOYMENTS.md. Landing #118 first, so the entry reads addresses from the published deployments.json, means the deploy populates the CLI rather than someone copying twenty addresses by hand for a network where a mistake is not correctable. #118 in turn needs #222 fixed first, since three of the last six releases published no assets at all.

Two things to settle when adding the entry: what the id and aliases should be, given paseo-v2 sets an ecosystem-flavoured precedent rather than a network-flavoured one; and whether mainnet should be the default, since DEFAULT_DOTNS_ENVIRONMENT is currently paseo-v2 and a silent default to a testnet is the same hazard class as #197.

The UI's dependency ordering is different from the CLI's and slightly better. It already resolves most contract addresses from the on-chain CDM meta-registry, so a mainnet entry there needs chain metadata rather than an address table. The exception is the three contracts it hardcodes because they are not registered on CDM: NAME_ESCROW_ADDRESS, POP_CONTROLLER_ADDRESS and POP_RESOLVER_ADDRESS, noted on #221. So the CLI's entry is blocked on #118 for its addresses while the UI's is not, but both need the deploy to have happened.

Start with packages/cli/src/utils/constants.ts and packages/ui/src/lib/networks.ts, then read #222 and #118 and the published deployments.json context. Done means both packages represent the selected mainnet metadata, while --env/DOTNS_ENV and UI network selection no longer fall back to testnet-only constants.