Recover account creation when confirmation is unavailable

[dnlbui]

What Changed

Account creation now leaves the loading state when an accepted registration cannot be confirmed. CreateAccountModal owns a bounded 35-second receipt check and offers Check account status while preserving the original identity.

• Persist the original username, address, transaction ID, keys, and private-account state for recovery after reload.
• Reconcile the original receipt or matching username/address without generating another identity or submitting another registration.
• Bound receipt requests with abort signals; classify success, rejection, and unavailable confirmation explicitly.
• Include pending identities in device-lock password changes and clear stale recovery state after deliberate account removal.
• Remove the obsolete promise-map service that could retain an unresolved registration waiter.

Fixed Flow

Accepted registration → save original identity → bounded confirmation checks → sign in on confirmation, report explicit rejection, or show a recoverable confirmation-unavailable state.

Check account status reuses that identity after a reload. It does not resubmit registration.

Why

The shared pending checker could remove an unconfirmed transaction after its deadline without settling the promise awaited by Create Account. The screen remained on “Creating account…” indefinitely. Modal-owned confirmation also avoids depending on a shared polling request that can remain stalled.

Missing confirmation is not proof that registration failed, so recovery preserves the original account and checks authoritative state before proceeding.

Validation

• Local-only harness (excluded from this PR): node tests/registration-confirmation.test.cjs — 17 passed, covering null/empty/malformed/stalled responses, success/rejection, late confirmation, matching/conflicting aliases, original-identity binding, reload, private accounts, device-lock changes, account removal, and wallet-refresh failure.
• node --check app.js and git diff --check passed.
• Temporary browser harness: 3 passed for normal confirmation, explicit rejection, and unavailable confirmation → reload → late success; exactly one simulated registration submission per scenario.
• Edited client loaded against the dev network: a real registration received a successful receipt, reached Chats with the expected username, cleared recovery state, and produced no page errors.
• Recovery UI visually checked at 470 × 900.
• Separate make-code-skimmable and independent review passes completed.

Scope is confirmation recovery after accepted registration; submission-stage network handling is separate.

Closes #1742