`buzz-admin generate-key` emits a hex secret that desktop onboarding rejects (expects `nsec1`)

## Summary

The bootstrapping path and the desktop onboarding path disagree on key encoding. `buzz-admin generate-key` prints a 64-char hex secret (and tells you to put it in `BUZZ_PRIVATE_KEY`), but the desktop app's **Use an existing key** field only accepts bech32 `nsec1...` and reports the hex secret as invalid. Nothing in either surface mentions the conversion, and no converter ships in the tree.

## Steps to reproduce

1. Bootstrap an identity the documented way: `buzz-admin generate-key`
2. Note the printed `Secret key:` (64 hex chars) and the hint `Set BUZZ_PRIVATE_KEY to the secret key.`
3. Launch the desktop app, choose **Use an existing key**, paste that secret

## Actual

The field stays in its pending state (`Waiting for a valid nsec1 key`) and **Next** never enables. The same secret works fine as `BUZZ_PRIVATE_KEY` for `buzz-cli`, so the operator has a key that is simultaneously valid (CLI, env) and invalid (GUI).

## Expected

Any one of:

- desktop accepts 64-char hex and normalizes it internally, or
- `buzz-admin generate-key` also prints the `nsec1` form (ideal — it is the only bootstrap path documented for a self-hosted relay), or
- the field's helper text names the expected encoding and points at a conversion path

## Why it bites self-hosters specifically

On a self-hosted relay, `buzz-admin generate-key` is how you mint the relay owner and every agent identity, and `buzz-admin add-member` takes the hex pubkey — so hex is the native currency of the whole server-side flow. The desktop app is then the one surface that will not take it. Hosted users never see this because their identity is created for them.

Happy to send a PR that adds an `nsec`/`npub` line to `generate-key` output if that is the direction you would want.

Start by tracing the `buzz-admin generate-key` output and the desktop app's **Use an existing key** validation, then compare them with the `BUZZ_PRIVATE_KEY` path used by `buzz-cli`. Confirm the intended encoding with maintainers; done means the documented bootstrap secret can be used in desktop onboarding, with the chosen conversion or acceptance behavior covered by the relevant checks.

Written by the indexing model from the issue text.