[Bug] Desktop profile conflates Nostr name with display name

## Problem

Buzz Desktop presents the first-community profile field as **Your username**
but persists that value as Nostr `display_name`. The same value is later shown
under **Settings → Profile → Display name**.

The Desktop profile model and Tauri command can read and preserve an existing
Nostr `name`, but neither onboarding nor Profile settings lets a user create or
edit it. A new user therefore cannot represent the standard two-field profile:

```json
{
"name": "alice",
"display_name": "Alice Example"
}
```

This affects new and existing Desktop users who want a short Nostr name and a
separate richer display name. It also teaches the user that they are choosing a
username when the emitted field has different semantics.

The canonical identity remains the public key. This issue is about profile
metadata and UI semantics, not account identity or authorization.

## Evidence And Reproduction

### Environment

- Observed release: Buzz Desktop `v0.4.25`
- Release commit:
`e8105d1446834f522c75d628bf1d9e77c9c077a4`
- Observed OS: macOS
- Current `main` rechecked at:
`b8510ede1b52ebe87ed3cf18cf0b2590a86b2245`
- Supported path: first-community onboarding followed by
**Settings → Profile**

### Minimal reproduction

1. Start first-community onboarding with an identity that has no profile event
in that community.
2. At **Build your profile**, enter `alice` into the field labeled
**Your username**.
3. Complete onboarding.
4. Open **Settings → Profile**.
5. Observe that the same value is labeled **Display name**, with no separate
`name` or username control.
6. Inspect the current source or capture the signed kind-0 event. The onboarding
payload supplies `displayName: "alice"`; it does not supply `name`.

### Current result

- Onboarding labels the input as a username.
- The input is stored as `display_name`.
- Settings correctly labels the stored value as **Display name**.
- A pre-existing kind-0 `name` is preserved by Desktop edits but cannot be
created or changed through the supported Desktop UI.

### Evidence classification

**Observed**

- On Buzz Desktop `v0.4.25` for macOS, first-community onboarding requested a
username.
- After onboarding, Profile settings displayed the resulting value as
**Display name** and exposed no separate username/`name` field.

**Code-proven**

- `desktop/src/features/onboarding/ui/CommunityOnboardingFlow.tsx` labels the
input **Your username**, uses username-oriented HTML attributes, and calls
`updateProfile({ displayName: ... })`.
- `desktop/src/features/settings/ui/ProfileSettingsCard.tsx` edits only
`displayName`, avatar, and about; it labels the field **Display name**.
- `desktop/src/shared/api/types.ts::UpdateProfileInput` has no `name` member.
- `desktop/src-tauri/src/commands/profile.rs::update_profile` accepts no `name`
argument. It only carries forward `name` when one already exists in the
current kind-0 content.
- The same behavior remains present on current `main` at the SHA above.

**Documented**

- NIP-01 defines `name` in kind-0 user metadata.
- NIP-24 defines `display_name` as a richer alternative to `name`, states that
`name` should still be set, and deprecates the literal `username` key in favor
of `name`.
- Review on PR #2088 rejected presenting the existing display-name field as a
username unless a real username model was introduced separately.

**Not yet runtime-proven in this report**

- A redacted raw kind-0 capture from the observed production community has not
been attached. The payload-to-field mismatch is code-proven on both the
release commit and current `main`.

## Expected Behavior

Buzz Desktop should represent Nostr profile metadata without conflating the two
fields:

- `name` is the short Nostr name/handle.
- `display_name` is the richer human-facing name.
- The supported Desktop profile flow allows a user to set and later edit both.
- UI labels describe the field that is actually signed and published.
- The public key remains the canonical identity; neither field is presented as
globally unique.
- Editing either field preserves the other field and all unrelated kind-0
metadata.

The exact layout is a product decision. The required outcome is semantic and
wire-level agreement between onboarding, settings, the update contract, and the
signed kind-0 event.

## Scope

- Buzz Desktop first-community profile onboarding.
- Buzz Desktop Profile settings.
- Shared Desktop profile/update types and Tauri command wiring needed to carry
`name`.
- Signed kind-0 profile construction for the current user's supported Desktop
path.
- Focused unit/integration/E2E coverage for the two-field round trip.

Owner boundary: `block/buzz` Desktop and its local Tauri profile command.

## Non-Goals

- NIP-05 domain provisioning or verification UI.
- Making `name` globally or community-wide unique.
- Changing public-key identity, community owner/admin roles, authentication, or
signing.
- Publishing profiles to additional public relays.
- Adding relay or database migrations.
- Modeling every optional kind-0 field.
- Reimplementing the general metadata-preservation work tracked by #2534 and
its open PRs.
- Changing managed-agent profile semantics.
- Broad profile-page redesign, unrelated onboarding polish, or cleanup.

## Acceptance Criteria

- [ ] A user can set both `name` and `display_name` through supported Buzz
Desktop profile flows.
- [ ] A profile saved as `name = "alice"` and
`display_name = "Alice Example"` emits a signed kind-0 containing those
exact fields.
- [ ] Reopening Profile settings displays both values in controls with
semantically correct labels.
- [ ] Editing only `name` preserves `display_name`, picture, about, NIP-05, and
unmodeled kind-0 fields.
- [ ] Editing only `display_name` preserves `name` and the same unrelated
metadata.
- [ ] An existing profile containing only `display_name` continues to load and
can be upgraded without silent data loss.
- [ ] An existing profile containing both fields round-trips without one field
being promoted into or replacing the other.
- [ ] Repeated saves with unchanged values are idempotent at the profile-content
level and do not delete unrelated metadata.
- [ ] Validation errors fail without publishing a partial replacement event or
showing unsaved values as canonical.
- [ ] The UI does not imply that `name` is globally unique or authoritative
over the public key.
- [ ] Existing avatar, about, key import, community onboarding, and profile
navigation behavior remains compatible.

## Validation Plan

- Add focused tests for Desktop profile update serialization with independent
`name` and `display_name` inputs.
- Add a regression test proving that updating either field preserves the other
and unmodeled kind-0 metadata.
- Add Desktop E2E coverage for:
- first-community onboarding;
- Profile settings edit/readback;
- exact raw kind-0 content after each supported path;
- returning profiles with only `display_name`;
- returning profiles with both fields.
- Run the repository-required Desktop checks and focused E2E tests.
- Run `just ci` before proposing implementation for merge.
- Record exact-head test evidence in the implementation PR. Auto-review belongs
to that PR and is not pre-claimed by this issue.

## Security And Compatibility

- No private key export or new signer is required; the existing local signer
remains authoritative.
- No auth scopes, permissions, community roles, secrets, network exposure, or
relay admission rules should change.
- No database migration should be necessary because the source of truth is the
signed kind-0 event.
- Existing profiles must remain readable without forced migration.
- The implementation must coordinate with the resolution of #2534 so a new
field editor does not reintroduce destructive whole-profile rewrites.
- No personal names, public keys, private community content, credentials, or
unredacted production event payloads are required in tests or issue evidence.

## References

- NIP-01 — Basic protocol flow and kind-0 metadata:
https://github.com/nostr-protocol/nips/blob/master/01.md
- NIP-24 — Extra metadata fields:
https://github.com/nostr-protocol/nips/blob/master/24.md
- Buzz issue #2534 — destructive kind-0 rewrite and unexposed `name`:
https://github.com/block/buzz/issues/2534
- Buzz PR #2545 — metadata-preservation implementation:
https://github.com/block/buzz/pull/2545
- Buzz PR #2606 — competing metadata-preservation implementation; explicitly
leaves exposing `--name` out of scope:
https://github.com/block/buzz/pull/2606
- Buzz PR #2088 review — distinguishes display name from a real username model:
https://github.com/block/buzz/pull/2088#pullrequestreview-4729588607
- Buzz PR #2118 — later onboarding change that reintroduced username copy while
retaining the display-name persistence path:
https://github.com/block/buzz/pull/2118