dotNS registry surface: the default Asset Hub contract addresses have no code on chain

[UtkarshBhardwaj007]

The tg-dotns-registry-impl branch hardcodes default contract addresses in dotns-abis.ts (registry 0x4Da0d37aBe96C06ab19963F31ca2DC0412057a6f, registrarController 0xd09e0F1c1E6CE8Cf40df929ef4FC778629573651; the file already carries a TODO doubting them). Checked them with pallet-revive dry runs (state_call ReviveApi_call): none of them has contract code on paseo-asset-hub-next, and none on the previewnet Asset Hub either. Calls return Ok with empty data. The same holds for the "Paseo Asset Hub Next V2" list in paritytech/dotns DEPLOYMENTS.md and for the registry in dotns-sdk's cdm.json (0xf62c2ece...), so picking any documented list is fragile.

The live deployment is discoverable from chain state with public getters, no hardcoding:

1. DotnsGateway.DispatcherAddress (pallet storage on Asset Hub)
2. dispatcher.TARGET() (RootGatewayDispatcher.sol, public immutable)
3. popController.protocolRegistry() (DotnsPopController.sol)
4. protocolRegistry.get(bytes32("registry")), same for "registrar", "reverseResolver", "contentResolver", "popRules" (keys in DotnsConstants.sol)

Verified on both paseo-asset-hub-next and the previewnet Asset Hub: the walk lands on the same deterministic CREATE3 set on both chains (registry 0xf34054fd76BbF85f216cf9908226D5f0A72E50CA, registrar 0x4f06E818Ba3d987704fd91cf3d868E4b019106Ab, and so on), and probes against the discovered addresses behave: registry.owner(namehash("dim2.paseo")) is owned on next, owner(namehash("dim2.dot")) is owned on previewnet, registrar.available(labelhash) answers. Runnable proof: dim2-spa apps/web/scripts/verify-uj6-dotns.mjs (deduction D9).

Ask: resolve the addresses through the gateway walk at runtime, or at least verify the hardcoded defaults against DotnsProtocolRegistry at startup and fail loudly on a mismatch. Also worth a look while in there: the branch derives availability from resolver-zero rather than the registrar's own available(), and those are not the same question once reservations exist.

Part of #286

[Imod7]

Done in #314. Both asks are in, the gateway walk and the startup check. Four differences from
what this issue asked for.

Asked here	Delivered	Why
The walk, or at least a startup check	Both. addressSource: "discovered" walks, verifyDotNsAddresses(opts) checks	The check is the walk plus a comparison
get(bytes32("registrar")) and get(bytes32("contentResolver"))	get(bytes32("controller")) and get(bytes32("resolver"))	Wrong contracts. registrar is the ERC-721, 0x4f06E818..., not the controller the SDK calls, 0xBdaA01bD...; contentResolver holds contenthash, not addresses. get returns a live address for both, so it would fail silently as a revert later. The address in this issue's own walk output is the ERC-721
Every address from get(...)	Five from get, plus protocolRegistry from step 3	It has no key, so it cannot be looked up in the registry it is
Resolve from chain state	Opt in, "pinned" stays the default	The table is correct today, verified on both networks. The walk costs four round trips, and DotnsGateway is absent from Polkadot and Kusama Asset Hub

The aside is already fixed. Availability has asked registrarController.available(label) plus
PopRules.classifyName since #293.

One correction from verifying this: Previewnet's TLD is .test, not .dot. This issue and #293
both record dim2.dot as owned there. Measured through the shipped code, Previewnet refuses
.dot and accepts .test, matching paritytech/dotns DEPLOYMENTS.md. Comments corrected in
#314, no behaviour depended on it.

Still open, not new: no automated live test, so nothing detects a redeploy moving an address. The
run above was by hand. verifyDotNsAddresses is what such a test would call.