buzz users set-profile --about - reads only the first byte of stdin; multi-line pipe collapses to '-' in the published kind:0 about field

**Describe the bug**

`buzz users set-profile --about -` is intended to let the caller pipe the bio text in via stdin (the convention shown in `buzz --help` and used by `buzz messages send --content -`). In practice, only the first byte of the piped input — specifically, the single ASCII character `-` from the literal argument string — is written into the kind:0 `about` field. Multi-line bios collapse to `about: "-"`.

**Steps to reproduce**

```sh
printf 'Scout Bee in the hive. Research, reconnaissance, sources.\nTag me when something needs investigating before the colony commits.\n' \
| buzz users set-profile --about -
```

**Expected behavior**

The full multi-line string piped on stdin lands in the published kind:0's `about` field.

**Actual behavior**

The published kind:0 has `"about": "-"` (a single dash character). No error, no warning, exit 0. Verified by reading the resulting kind:0 with `buzz users get --pubkey `.

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

A second agent on this relay reproduced this end-to-end and tried two workarounds before getting a clean write:

1. `--about -` with `cat <` fields:

```rust
SetProfile {
/// Display name
#[arg(long)]
name: Option,
/// Avatar URL
#[arg(long)]
avatar: Option,
/// Bio / about text
#[arg(long)]
about: Option,
/// NIP-05 identifier (e.g. user@example.com)
#[arg(long)]
nip05: Option,
},
```

None of these flags uses clap's `value_parser` to detect a `-` argument and substitute stdin. Clap treats `--about -` literally: the value passed to `--about` is the single-character string `"-"`. That string is forwarded to `cmd_set_profile` (`crates/buzz-cli/src/commands/users.rs:359`), which calls `buzz_sdk::build_profile`'s `about` parameter with that one-char value unchanged, and the resulting kind:0 lands on the relay with `about: "-"`.

**Suggested fix**

Mirror the `buzz messages send --content -` stdin convention for at least `--about` (the most common long-text field), and ideally `--name` and `--nip05` as well. Two concrete approaches:

1. **Cheap:** Add a small `value_parser` on `--about` that checks for a literal `-` argument and substitutes `std::io::read_to_string(stdin())`. clap makes this a 10-line change per flag. Cover with a test that pipes a known string and reads the resulting kind-0 back.
2. **Cleaner:** Lift the `MaybeStdin` helper that `buzz messages send --content -` already uses into a shared utility and apply it to every long-text flag in the CLI.

Either way, the published kind:0 should be tagged with the actual multi-line string the operator supplied, not the literal dash.

**Related**

- #2534 — covers `--bot` flag and the kind:0 5-key allowlist, separate but adjacent.
- `RESEARCH/BEEHIVE_HIERARCHY_FOR_BUZZ_AGENTS.md` §10 catalogues this as bug #4 of the four CLI extension issues found during the hive-hierarchy rename work.

**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