fix(identity): gate the signer actually in use; 'Log in first' when not logged in

[ReinhardHatko]

Unblocks the E2E suite, which has been red on main since at least 2026-08-28, and fixes a misleading notice for real users.

The gate checked the wrong account

enforceIdentityGate always resolved the phone login session, whatever signer the command was told to use. A headless run with --suri or --signer dev and no session was therefore blocked as not-logged-in — and that status was titled "Join the competition first", so it read as an identity problem rather than a missing login. Every E2E deploy/mod test hit it.

The registry's require_revealed is decided on env::caller(), the account that actually publishes. The gate now asks about that account:

Invocation	Account the gate checks
--suri <key> (deploy, deploy-all, decentralize, mod)	that key's H160
--signer dev (no --suri)	the dev publish account (DEV_PUBLISH_ADDRESS)
neither	the logged-in phone session (unchanged)

resolveActingH160 in identityGate.ts is the single place that maps flags to an account; checkIdentityGate takes an optional account and skips the session lookup when given one.

playground mod --suri was a documented no-op (mod never signs). It now only selects which account the gate checks; the help text says so.

"Log in first"

The not-logged-in notice now has its own title, "Log in first", and leads with playground login. anonymous and unverifiable copy is unchanged.

E2E setup

• Bulletin quota. The deployer's Bulletin authorization was still active but had remainingTxs: 0, and the template-registration store was rejected as Invalid.Payment — at a 6000 PAS balance, so funding did not help. globalSetup now calls ensureAllowance for the deployer before registering the template (soft-fail, like the registration itself).
• Mod tests sign the gate check as the funded E2E deployer instead of //Alice.

Verified live on paseo-next-v2: the wired verifier returns revealed for the E2E deployer, //Bob, and the dev publish account.

E2E registry reads used the pre-v2 shape

e2e/cli/fixtures/registry.ts::getApp (and the readback in tools/register-e2e-fixtures.ts) still narrowed getMetadataUri on a pre-v2 Option's isSome. The v2 registry returns a plain string, so every app read as missing:

• globalSetup re-registered the template on every run, in every cell at once — the source of the Invalid.Stale nonce collisions;
• every deploy test that asserts the registry entry after a deploy could never pass.

Both now decode through getAppMetadataUri, the CLI's single decoder for this call (it throws on an unexpected shape rather than reading as "not found"). Verified live: the template fixture reads as registered with the CID CI wrote.

Tests that asserted pre-gate behaviour

• mod.test.ts — the no-login, no---suri case expected mod to go straight to the registry lookup. It now pins the gated outcome: "Log in first", exit 0, no lookup. The --suri registry-miss test still covers "not found in registry".
• session.test.ts — the corrupted-session test corrupted dot-cli_SsoSessions.json, a name nothing has read since host-papp 0.8.7, so it tested an empty home. It now corrupts dot-cli_SsoSessionsV3.json (which reads as "no session") and asserts "Log in first" with nothing signed. Ran the exact command locally against that home to confirm.

pr-deploy-cdm: build cargo-pvm-contract on its pinned toolchain

cdm setup runs cargo install from outside its clone, so cargo-pvm-contract's own rust-toolchain.toml (1.92) is ignored and the build used the workflow's floating nightly. Nightly 1.101 (2026-09-28) changed never-type fallback (rust#148922) and trie-db stopped compiling — the toolchain step has failed on every run since at least 2026-08-30. The workflow now reads the pinned channel from upstream and runs the install under it; contract builds stay on nightly (the fixture contracts do not depend on trie-db). Built the same main commit locally on 1.92 with --locked to confirm.

Follow-up, not in this PR

A blocked gate exits 0 (a soft outcome, by design since #413). For non-interactive use that means a script running deploy --signer phone with no login sees success. Worth deciding separately whether headless runs should exit non-zero.

Testing

pnpm test 1039 passed (new cases for the explicit-account path and resolveActingH160) · tsc --noEmit clean · format:check ✓ · lint:license ✓.

[github-actions]

Dev build ready — try this branch:

curl -fsSL https://raw.githubusercontent.com/paritytech/playground-cli/main/install.sh | VERSION=dev/rh/e2e-identity-gate-acting-signer bash

[github-actions]

E2E Test Pass · ✅ PASS

Tag: e2e-ci-pr · Branch: rh/e2e-identity-gate-acting-signer · Commit: 5fbc0dc · Run logs

Cell	Result	Time
pr-mod	✅ PASS	2m08s
pr-deploy-frontend	✅ PASS	6m46s
pr-deploy-foundry	✅ PASS	0m49s
pr-login-session	✅ PASS	1m54s
pr-install	✅ PASS	0m45s
pr-preflight	✅ PASS	2m10s
pr-deploy-cdm	✅ PASS	3m56s
${{ matrix.cell }}	⏭️ SKIP	0m-1s
${{ matrix.cell }}	⏭️ SKIP	0m-1s

Sentry traces: view spans for this run