Desktop: "Start new identity" at the lost-identity prompt strands the user with no route back to recovery

## Summary

If Desktop loses its local identity and the user picks **Start new identity** at that prompt, they are permanently stranded: the new identity is not a member of their community, so the first profile publish (`kind:0`) is refused by the relay, and **there is no way back to the recovery option from that screen**. Recovery is only reachable from the screen the user has already clicked past.

The only escape is to delete the app's credential from the OS keychain to force a fresh first run — which is undiscoverable, and destructive (see the note at the end).

## Environment

- Buzz Desktop 0.5.11, macOS 26.4, Apple Silicon, signed release app in `/Applications`
- Hosted community relay (`.communities.buzz.xyz`), user is the community **owner**
- A signed-in Buzz phone with the original identity was available the whole time

## Reproduction

1. Launch Desktop in a state where it reports the local identity is lost.
2. Choose **Start new identity**.
3. Complete the community step.
4. Arrive at **"What should we call you?"** and enter any name.
5. Press **Continue**.

## Actual behavior

The name step fails with:

> **Server error — try again**
> The relay returned an error. Try again.

The underlying cause is that the freshly created identity is not a member of the community, so the profile publish is rejected. Probing the relay with an unrelated key returns the same class of rejection, cleanly:

```
{"error":"auth_error","message":"relay error 403: relay_membership_required","retryable":false}
```

The client surfaces this as a generic "Server error", giving the user no indication that the problem is membership rather than a transient relay fault. "Try again" can never succeed.

**And there is no navigation out of the screen:**

- **Back** opens a "Change community" modal (community name / relay URL) — not identity.
- The **Buzz** menu contains only About, Services, Hide, Quit.
- The **View** menu contains only Toggle Full Screen.
- There is no Settings/Preferences item, no account or identity control, and no way to reset onboarding.

The user is pinned on step 2 of 2 with one forward action that always fails.

## Expected behavior

- The identity step should be reachable from anywhere in onboarding — e.g. a "Use an existing identity / recover from your phone" affordance on the name step, or a working Back that returns to the identity choice rather than to community settings.
- The membership rejection should be reported as what it is ("this identity is not a member of "), with the recovery path offered inline, instead of a generic retryable "Server error".
- Ideally the lost-identity prompt should make the consequence of **Start new identity** explicit: it creates a *different* identity that will not have your community membership, your ownership, or your agents.

## Impact

This is a one-click, irreversible-from-the-UI trap at exactly the moment a user is least equipped to make the call — they have just been told their identity is lost. In our case the user was the relay **owner**; choosing "create new" would have meant abandoning ownership, since the owner pubkey is fixed in the relay's configuration and cannot be reassigned by an invite.

## Note on the workaround

The only route out is to quit the app, delete the `buzz-desktop` credential from the login keychain, and relaunch to reach first-run. That is destructive in a way that isn't obvious: that single keychain item is the container for **all** identities the app manages, including managed-agent keys. Filed separately.