Add the mainnet network preset once the dotNS mainnet deploy lands

[filip-parity]

The last open box of #397. Everything else about the dotNS-on-Asset-Hub username migration is merged (#426); the mainnet preset cannot be prepared in advance because the contract addresses only exist once the deploy runs (paritytech/dotns#223), and hand-transcribing them would repeat the drift paritytech/dotns#221 documents.

What the preset needs when the deploy lands:

• Mainnet People / Bulletin / Asset Hub endpoints and genesis hashes in truapi-host-cli/src/network.rs (per-chain ChainEndpoint constants; the SPEC §14.1 table and js/packages/truapi/src/well-known-chains.ts are pinned to the presets by tests, so all three move together).
• The identity backend base for production, with the dotNS gateway enabled there (the testnet-next environment currently answers POST /usernames with "dotNS gateway is not enabled in this environment"; SPEC §14.1 documents the constraint).
• A rework of the every_preset_is_a_test_network guard and the CLI account store: it keeps disposable BIP-39 entropy on the assumption that every preset is a test network, so a production preset must not share that storage as-is (network.rs documents this on the Network enum).
• Ideally the addresses read from the published deployments.json rather than transcribed ([Feat]: Publish deployments and manifest as part of ABI release artifacts dotns#118 / Post-W3F API changes: signWithAccount, getPrimaryDotNsName, certifications, product keys #222 ordering, per [Bug]: The CLI and the UI cannot target mainnet: no mainnet configuration exists dotns#223).

Blocked on: the dotNS mainnet deploy (paritytech/dotns#223).

[filip-parity]

This remains still blocked on the mainnet deploy (paritytech/dotns#223, no assignee, untouched since August 13 yeyyy). Once paritytech/dotns#242 lands, the addresses can be read from the release's deployments.json instead of hand-transcribed, which removes the drift risk this issue calls out.