fix(cli): buzz messages send --content - publishes an empty message when stdin is empty; should be a hard error

### Summary

`buzz messages send --channel --content -` reads the message body from stdin. When stdin is empty, the command exits 0, the relay accepts the event, and an **empty kind-9 message is published to the channel**. Publishing an empty message should be a hard CLI error.

This is not hypothetical: one of our community agents constructed a broken shell pipeline and silently published an empty reply. The agent's own model output was fine; the pipeline was wrong; the CLI happily notarized and published a whitespace-only message.

### Repro

```bash
# publishes an empty message, exit 0, relay accepts:
printf '%s\n' "$UNSET_VAR" | buzz messages send --channel --content -
```

Result observed in relay DB: kind-9 event with content = a single newline, `accepted: true`, and the CLI's own success JSON reports `"message": ""`:

```json
{"accepted":true,"event_id":"f94d7886...","mention_pubkeys":[],"message":""}
```

### Why it matters

- An agent (or script) that mis-constructs its pipe gets a **success** response for an empty publish. Nothing in the exit code or the JSON flags the emptiness, so the caller has no signal to retry
- The channel then shows a ghost empty bubble; recipients see "Buzzy: (empty)"
- `--content -` exists precisely so callers can stream content safely; a silent empty-input pass-through undermines that contract

### Suggested fix

In the `--content -` path, after reading stdin to EOF: if the trimmed content is empty (or whitespace-only), fail with a non-zero exit and an error like `error: empty message content from stdin; nothing published`. Same guard for empty `--content ""` passed inline.

Optionally: a `--allow-empty` escape hatch if some legitimate use exists, though I can't think of one; an empty message has no recipient value and the relay could equally reject it server-side.

### Environment

- buzz CLI / desktop 0.5.23 (also observed on 0.5.20), Linux, self-hosted relay
- Observed 2026-09-07, relay event f94d788668d37014f1e4b7f3280ba7d61c71c1d4001d1db83a1f9a23c0e7373d (content: single `\n`)

### Related

- #4923, #7425: agent reply-delivery reliability cluster; this is the third way a reply can silently fail or mislead