buzz users set-profile --name writes display_name, not the Nostr kind:0 name field; no --display-name flag and no CLI path to set the username

**Describe the bug**

`buzz users set-profile --name "Foo"` does **not** write to the Nostr kind:0 `name` field, despite what the flag name implies. It writes to `display_name`. This is the opposite of what the help text says ("Display name") and the opposite of what NIP-01 callers expect. Operators who believe they are populating the canonical Nostr `name` field (the short username / NIP-05-like handle) are actually setting the long display name, and there is no CLI path to set the real `name` field today.

**Steps to reproduce**

```sh
buzz users set-profile --name "Forager Bee"
```

Then read the profile back:

```sh
buzz users get --pubkey
```

**Expected behavior (per `--help` and NIP-01 convention)**

The kind:0 should have `"name": "Forager Bee"`, leaving `display_name` available for the long display label.

**Actual behavior**

The kind:0 has `"display_name": "Forager Bee"` and no `name` key. The user's account on `avdhesh.bee` demonstrates the field exists: that profile has both `name` and `display_name` populated, and the only way to populate `name` today is through a non-CLI writer (Buzz Desktop profile editor, or hand-crafted kind:0).

**Why this matters**

- **Help text says one thing, CLI does another.** `buzz users set-profile --help` documents `--name` as "Display name", but `--name` is also the canonical NIP-01 field name. The CLI is ambiguous between the two and lands on neither.
- **Hinders agent rename hygiene.** When renaming an agent (e.g. Fizz → Forager Bee as part of a hive-hierarchy migration), the only place to write the new long label is the same flag as the short handle. Operators lose the ability to keep `name` = old short handle for backward-compatibility in mentions while `display_name` flips to the new caste label.
- **Disclosure flag impact.** When the kind:0 republish drops `bot: true` (see #2534), the user has no CLI path to re-set it without a Desktop round-trip. The `--bot` flag should also exist alongside a working `--name` so the rename flow is self-contained on the CLI.

**Reproduction confirmed on the live relay (2026-08-31)**

A second agent on this relay performed Fizz → Forager Bee kind:0 rewrite via the CLI. After `set-profile --name "Forager Bee" --about "…"`, reading the resulting kind-0 back showed `display_name: "Forager Bee"` and no `name` key. The old handle was preserved in `about` only, as a textual workaround.

**Root cause (from reading the source)**

`crates/buzz-cli/src/lib.rs:856-869` defines `--name` as the user-facing flag, with no `--display-name` alias and no separate Nostr-`name` flag. In `crates/buzz-cli/src/commands/users.rs:376-389`, `merged_name` (the variable built from the `--name` flag value) is passed as the **first argument** to `buzz_sdk::build_profile`, which `users.rs:411` explicitly documents as the display name: `` `name` field (username) — not exposed by CLI ``. The Nostr-`name` argument (the second slot in `build_profile`) is hardcoded to `None`, with the comment "not exposed by CLI".

```rust
let builder = buzz_sdk::build_profile(
merged_name.as_deref(),
None, // `name` field (username) — not exposed by CLI
merged_picture.as_deref(),
merged_about.as_deref(),
merged_nip05.as_deref(),
)
```

**Suggested fix**

1. **Rename `--name` to `--display-name`** to match what the field actually writes. This is the cheapest fix and aligns the CLI flag with the kind:0 field it targets.
2. **Add a separate `--name` flag** that writes to the Nostr `name` field. The current `--name` semantic moves to `--display-name`; the new `--name` writes the short username.
3. **Update `cmd_set_profile`'s merge logic** so `display_name`/`name` are independent and both round-trip on a partial update. Today the merge chain `merged_name = display_name → current.display_name → current.name` silently promotes a `name`-only profile to `display_name`-only on rewrite.
4. **Consider aliasing both directions** (`--display-name` as the new canonical, `--name` for the Nostr field, with a deprecation warning if `--name` is used the old way) to avoid breaking existing automation that relies on `--name "X"` writing `display_name`.

**Related**

- #2534 — covers the kind:0 5-key allowlist and `--bot` flag in the same surface area, but does **not** call out that `--name` writes the wrong field.
- `RESEARCH/BEEHIVE_HIERARCHY_FOR_BUZZ_AGENTS.md` §5 (CLI capabilities and the empirical read that exposed this) and §10 (catalogue of CLI extension issues).

**Version and platform**

- Buzz version: latest main (`571c190` on `avdheshcharjan/buzz` as of 2026-09-01)
- OS: macOS, reproduced via the bundled `buzz` binary against a live relay

Start with the argument definitions in crates/buzz-cli/src/lib.rs:856-869 and the set-profile merge and build_profile call in crates/buzz-cli/src/commands/users.rs:376-411. Reproduce the issue with the set-profile and users get commands, then trace how existing profile fields are merged. Done means the CLI can independently round-trip Nostr name and display_name fields, with help text and compatibility behavior matching the chosen flag semantics.

Written by the indexing model from the issue text.