security: `--private-key` as a CLI argument leaks the key into shell history and process listings

Several `buzz` subcommands accept the identity secret directly on the command line, e.g.:

```
buzz channels remove-member --relay --private-key \
--channel --pubkey
```

Two consequences:

1. **Shell history.** The full `nsec1...` is written verbatim to `~/.zsh_history` and to every per-session file in `~/.zsh_sessions/`. These are plaintext, included in Time Machine backups, and readable by any process running as that user. Users generally don't realise a one-off admin command has persisted their signing key to disk.
2. **Process listing.** While the command runs, the key is visible in `ps aux` to any local user.

Once it has happened, cleanup is unreliable — history files, editor undo state, backups and search indexes all need scrubbing, and the practical remedy becomes key rotation.

### Suggested fix

- Read the secret from an env var, stdin, a mode-0600 file, or the platform keystore. Keep `--private-key` only as a deprecated alias that warns.
- If argv support must stay, accept `--private-key-file` / `--private-key-stdin` and document those as preferred in `--help` and the docs.
- Consider a `buzz` config/keystore path so admin commands need no secret on the command line at all.

Related: #2883 (keeping `BUZZ_PRIVATE_KEY` out of agent-controlled processes) and #3629 (key rendered in `--help` output, fixed) — same class of exposure, different surface.

Buzz CLI as bundled with Desktop 0.5.3, macOS 26.5.2, zsh.