Deploy #275 (DotnsPopController with isPopIssued / dotted lite names) to previewnet

Ask

Please bring previewnet's DotnsPopController up to #275. previewnet is running the contract generation from before it, while paseo-next already has it.

Why

host-rust-core main (since paritytech/host-rust-core#602) reads lite usernames the #275 way: every label is gated on DotnsPopController.isPopIssued(string), and lite names are expected in stored dotted form (alice.42). On previewnet neither holds, so a host built from main cannot create a lite person on previewnet — onboarding polls isPopIssued 30 times, every call reverts, and the CLI aborts with "dotNS username did not appear on Asset Hub after attestation" even though the People chain has already recorded the person and the identity backend accepted the name (202, QUEUED).

Evidence

Same controller address on both networks, same protocolRegistry(), same owner() — only the provenance read differs:

controller 0xcc932348606cc1f3318cadec5a5cd2ca447f8a4b

                          previewnet                      paseo-next
protocolRegistry()     -> 0xd19e3d0c…fa846e               0xd19e3d0c…fa846e
owner()                -> 0x4a519c30…cce099               0x4a519c30…cce099
isPopIssued(string)    -> contract reverted: (empty)      false

On previewnet the revert is identical for issued names in daily use (letsgoooo.36, stalectl.80), for freshly queued names, and for names that never existed; no variant of the capability exists (popIssued, isIssued, isPopName, the bytes32 forms, chatKey, usernameNodeOf, nameOf all revert). That is an absent selector, not a state answer. Labels on previewnet also still come back flattened (alice42).

Probe: ReviveApi_call via state_call against wss://previewnet.substrate.dev/asset-hub and wss://paseo-asset-hub-next-rpc.polkadot.io, controller discovered from DotnsGateway.DispatcherAddress, calldata isPopIssued(string).

Impact

Downstream products on previewnet (e.g. humanity-spa's weekly-game seat, which needs a lite person with correctly derived keys) currently have no working host: the released truapi-host 0.13.1 onboards but predates the key-derivation fix (host-rust-core#627), and main has the fix but cannot onboard against the pre-#275 contracts. Deploying #275 to previewnet lets main work there as it already does on paseo-next.

Note: #275 changes storage for new names; labels minted under the old contracts stay flattened, which is fine — those persons are unusable for the unrelated key-derivation reason anyway.

Context and full trail: paritytech/host-rust-core#720.

Start with #275 and compare the DotnsPopController deployment on previewnet with paseo-next, using the documented ReviveApi_call/state_call probe as the verification entry point. Deploy the #275 contract changes to previewnet, then confirm isPopIssued(string) responds and newly created lite names use dotted storage before validating host-rust-core main onboarding.