Windows onboarding says it will create a new identity after an existing identity was migrated

[C0dino]

Summary

When a release build starts with a valid legacy identity file before machine onboarding has completed, the backend migrates that identity into Windows Credential Manager, but the first screen still offers Create a new identity key rather than recognizing the active identity.

Reproduction

1. Install Buzz Desktop 0.5.3 on a clean Windows 11 user profile.
2. Before the first machine-onboarding flow completes, place a valid existing identity in the supported legacy identity file location.
3. Start Buzz and verify that the backend migrates the identity into the system keyring and removes the legacy file.
4. Observe the first machine-onboarding screen.

Expected

The screen recognizes the already loaded identity and offers Continue setup or an equivalent action that names the current public identity, with Use a different key as the alternative.

Actual

The primary action still says Create a new identity key. The action calls the existing-identity read path and continues setup; it does not actually create a new identity, so the label contradicts the behavior.

Environment

• buzz: desktop-v0.5.3 release build
• os: Windows 11
• identityStorage: Windows Credential Manager after supported legacy-file migration

Impact

Managed or recovery-oriented deployments can make users believe that continuing will replace their existing identity. That creates avoidable identity-loss anxiety and can push users toward an unnecessary second import path.

Workaround

Independently verify the active public identity, then use the primary action; despite its label, the current implementation reads the existing identity and continues setup.

Disclosure check

• Client data: no
• Credentials or private hosts: no
• Reproduction contains only synthetic or product-level evidence