paseo-next-v2: PoP whitelist request for deploy signer + personhood self-serve broken by derivation skew

Whitelist request

Please grant ProofOfPersonhoodFull (POP_RULES setUserPopStatus) on paseo-next-v2 to our CI/service deploy signer so we can re-register our premium label after the recent re-genesis:

• SS58 (root of the service mnemonic): 5EHwDR8ryK9ggn6S7cZTdTAN1rpFEqTE4pk2VNRFZKGXnZHx
• H160: 0x778122c205ad9530fa085bd24dd426693343a5b4
• Label: atelier (previously deployed as atelier.paseo before the wipe; we've fallen back to the NoStatus-shaped atelierapp00.paseo in the meantime)

Bug report: the self-serve loop is broken for CLI signers

Following the exact remediation printed by bulletin-deploy@0.16.1 (personhood-faucet → dotns-bootstrap) cannot succeed, because sudo.personhood.dev and bulletin-deploy derive different member keys and different accounts from the same mnemonic:

1. For a freshly generated mnemonic, the faucet registered member key 0x8d63a928… (PersonalId 8, finalized at 0x5d7a603a9e906b6323b190b4fb30fa493f7ad87fdd5d046fb1a342187f460ccf), while bulletin-deploy@0.16.1's deriveMemberKey (blake2b-256 keyed "candidate" over BIP39 entropy → member_from_entropy) yields 0xbdcbd689… for the same phrase. The CLI therefore reports NoStatus / cannot build ring proofs for an identity the faucet just registered.
2. The account the faucet binds (label //product//dim2.dot/0, which appears to be a hardcoded default) is not reproducible from the mnemonic via standard SURI derivation either (sr25519/ed25519, many junction parsings tested), so --derivation-path cannot make the deploy sign as the bound account.
3. For a mnemonic registered pre-wipe, the faucet backend replies "this key is already known — no submission needed" and replays the old-scheme member key (0xfb3e8078…), so the current-scheme key can never be registered for it.
4. Minor: runBootstrap's state probe reads AliasAccounts.AliasFee from storage; on the current paseo-next-v2 runtime it is a Config constant (not in metadata), so the probe throws Runtime entry Storage(AliasAccounts.AliasFee) not found before its ?? 0n fallback can apply.
5. The dotns-bootstrap page's own Pgas.claim_pgas also failed for us with {"type":"Invalid","value":{"type":"BadProof"}} (old identity, ring rev 3 at the time).

Also of note: Alice is NoStatus on paseo-next-v2 post-wipe, so the no-mnemonic worker path cannot register PoP-gated labels either.

Happy to provide more detail or test a fix.

Start with bulletin-deploy@0.16.1's deriveMemberKey and runBootstrap entry points, then compare their derivation and storage assumptions with the faucet and dotns-bootstrap behavior described here. Reproduce the member-key, bound-account, AliasFee, and BadProof failures; done means a registered mnemonic produces matching identities and the documented self-serve bootstrap completes on paseo-next-v2.