fix(desktop): clarify identity key button when key exists

[Chessing234]

Summary

• backing out of the backup step and clicking the CTA again reuses the existing key
• the button still said "Create a new identity key", which is misleading for a security-sensitive action
• when a key is already loaded, label it "Continue with existing identity key"

Closes #2318

Test plan

• first-run: button still says "Create a new identity key"
• create key → backup → back: button says "Continue with existing identity key" and shows the same key

Made with Cursor

[Chessing234]

button label switches to "continue with existing identity key" once a key is already loaded.

[wesbillman]

The behavior change makes sense: after the first successful getIdentity() call, backing out preserves selectedPubkey, and this CTA reopens the same key rather than creating another one.

Before merging, please update the existing E2E coverage in desktop/tests/e2e/onboarding-backup.spec.ts. The test at lines 80–91 currently backs out from the backup screen and explicitly expects Create a new identity key; it should instead assert the new label. That also directly covers the regression described in #2318.

Two copy suggestions:

• View existing identity key describes the immediate action more precisely than Continue with existing identity key, since the CTA opens the backup/key display again.
• The pending label should ideally be Loading identity…, not Saving identity…, because this path calls get_identity.

[morgmart]

🤖 Comment from Morgan's AI agent, reviewed by Morgan.

Thanks for the fix — the back-out case is real and worth solving. But I'd suggest a different shape for the returning state, because the current copy has two problems:

1. The two buttons clash. "Continue with existing identity key" and "Use an existing key" read as near-synonyms to a fresh user. The distinction (the key this app just generated vs. a key you're bringing from elsewhere) lives entirely in our heads, not on the screen.

2. "Existing" overstates what happened. The user hasn't set up an existing identity anywhere — they just backed out one step. Copy that implies a verified prior identity promises more than the moment warrants.

Proposal — reframe the returning state as continuing setup, not a key choice:

Once the user has clicked through to the backup screen, the landing screen isn't really a fork anymore — they already picked a path. So when they come back:

• Primary: Continue setup
• Secondary: Use a different key instead — same import flow, just relabeled for this state so it reads as the escape hatch it now is

This avoids two buttons competing over the word "existing," and "Continue setup" matches the user's actual mental state: they were mid-setup and want to keep going.

One mechanical note regardless of copy direction: the existing test at onboarding-backup.spec.ts:80–91 still asserts the old label — it's why the Desktop Smoke E2E (3) shard is red. It'll need to assert whatever the new state's label ends up being.

[Chessing234]

good catch — switched to continue setup / use a different key instead, loading identity… for the pending label, and updated the e2e assertion

[tlongwell-block]

Thank you, @Chessing234!