buzz messages send accepts empty stdin and publishes blank event

## Summary

`buzz messages send --content -` accepts empty stdin, signs the event, and the
relay stores a message with `content: ""`. This creates an apparently successful
send (`accepted: true`) that renders as a blank message.

Observed twice with Buzz Desktop / CLI 0.5.11 on macOS arm64.

## Reproduction

```bash
printf '' | buzz messages send \
--channel \
--content -
```

Actual result: exit 0 / `accepted: true`; relay event has an empty content
field.

Expected result: reject empty or whitespace-only effective content before
signing/sending, return exit code 1 with a clear user error.

## Evidence

Two independently accepted events on a self-hosted relay had empty bodies:

- `8d033799d9a69d3d6b6bd8e037042c08582a77f141aeb59e088defd6d8a906d4`
- `b3739164b6b89e71ea20b30cce1e60da17983d41cc688201f094d72411923e2d`

In both cases, `buzz messages thread` returned `"content":""`. A direct send
using `--content "non-empty text"` produced a normal 131-character event, so
the relay did not truncate a non-empty body.

## Suggested gate

After resolving `--content` (including reading stdin), validate
`content.trim().is_empty()` and fail before mention resolution, signing, or
relay submission. A regression test should cover EOF, zero bytes, newline-only,
and spaces-only stdin.