fix(deploy): stop numbering re-sent phone requests as new steps

[ReinhardHatko]

When the phone doesn't answer a signing request, the deploy re-sends it. Every re-send was numbered as the next step, so a user who had approved nothing saw approve step 3: Link content (DotNS setContenthash) on a deploy that needs two approvals (Link content, then the registry publish). Reported live on v0.48.0.

Two bugs

1. The step counter numbered requests, not approvals. bulletin-deploy times out an unanswered request and calls signTx again for the same operation, often while the first call is still pending. So a request that never completed is the signal, not a rejection. #549 fixed the wording, but only in the --yes output of deploy. The interactive deploy screen, decentralize, contract deploys, and the headless contract/decentralize paths all still printed the raw request number.

2. The DotNS label advanced per call, too. maybeWrapAuthForSigning picked labels[seen] with seen counting signTx calls. So for a new domain, a re-sent "Reserve domain" request was relabelled "Finalize domain". decentralize carried its own copy of the same logic.

Changes

• createSigningCounter numbers approvals: a request that repeats the label of an uncompleted one is the same step, next attempt. A completed step with a repeated label (the DotNS fallback label) is still a new step, and a late completion of an earlier step can't close the current one.
• wrapDotnsSigner (new, in signingProxy.ts) advances the label only on a completed signature (max(completed, index + 1), so an abandoned attempt that completes late can't skip a label). Both deploy and decentralize now use it.
• phoneApprovalCopy.ts holds the re-send notice shared by PhoneApprovalCallout and the line output. This replaces the label-keyed module-state map in deploy/index.ts, which also misread two legitimately separate operations with the same label as a retry.

A re-send now renders as:

╭──────────────────────────────────────────────────────────────╮
│ Check Your Phone                                             │
│ approve step 1: Link content (DotNS setContenthash)          │
│ No response yet — re-sent to your phone (attempt 3).         │
│ If no prompt appeared, open the Polkadot app and keep it in  │
│ the foreground.                                              │
╰──────────────────────────────────────────────────────────────╯

This only changes what the CLI reports. It doesn't change why the phone showed no prompt; the usual cause is the app not being in the foreground.

Verification

pnpm format:check ✓ · pnpm lint:license ✓ · tsc --noEmit 0 errors (run directly) · vitest 1043 passed.

The new tests reproduce the live report: three unanswered Link content requests are step 1, attempts 1–3, and the publish that follows is step 2. Checked by mutation: restoring the old counter fails 7 of the new tests, and restoring per-call labelling fails 2.

🤖 Generated with Claude Code

[github-actions]

Dev build ready — try this branch:

curl -fsSL https://raw.githubusercontent.com/paritytech/playground-cli/main/install.sh | VERSION=dev/rh/phone-retry-labels bash

[github-actions]

E2E Test Pass · ✅ PASS

Tag: e2e-ci-pr · Branch: rh/phone-retry-labels · Commit: f5ce476 · Run logs

Cell	Result	Time
pr-deploy-cdm	✅ PASS	3m31s
pr-mod	✅ PASS	1m37s
pr-deploy-foundry	✅ PASS	0m42s
pr-preflight	✅ PASS	2m36s
pr-install	✅ PASS	0m52s
pr-login-session	✅ PASS	1m52s
pr-deploy-frontend	✅ PASS	7m10s
${{ matrix.cell }}	⏭️ SKIP	0m00s
${{ matrix.cell }}	⏭️ SKIP	0m00s

Sentry traces: view spans for this run