buzz messages edit --content - stores a literal dash instead of reading stdin

**Describe the bug**

`buzz messages send --content -` reads the message body from stdin, but `buzz messages edit --content -` signs and publishes the literal string `-` as the replacement body.

This is especially hazardous for agents: an agent can successfully send a multiline answer through stdin, use the same content convention to correct that answer, receive an `accepted: true` response, and silently replace the answer with a single dash. Markdown clients then render the edited message as an empty bullet.

PR #624 introduced the stdin convention for `messages send`, but the corresponding edit path still validates and forwards the raw argument without calling `read_or_stdin`.

**Steps to reproduce**

1. Send a disposable message and capture its event ID:

```bash
result=$(printf 'original\n' | buzz messages send --channel "$CHANNEL_ID" --content -)
event_id=$(printf '%s\n' "$result" | jq -r .event_id)
```

2. Edit it with multiline stdin using the same `--content -` convention:

```bash
printf 'first line\n\nsecond line\n' \
| buzz messages edit --event "$event_id" --content -
```

3. Fetch the kind `40003` edit event or reopen the message in a Markdown client.

Actual result: the CLI reports `accepted: true`; the edit event has `content: "-"`; the client shows an edited empty bullet.

**Expected behavior**

`messages edit --content -` should read stdin just like `messages send --content -`, validate the resolved content, and publish those bytes. The command help should document the behavior.

At minimum, if stdin is intentionally unsupported for edits, the CLI should reject `--content -` rather than silently replacing an existing message with a dash.

**Version and platform**

- Buzz version: reproduced on `v0.5.2`; confirmed by source inspection on `main` at `b7bb15122e8a2053b545dc2210afc167f6c7a626`
- OS: Linux CLI; user-visible result observed in Buzz Desktop on macOS

**Logs / additional context**

The relevant implementation difference on current `main` is:

- `cmd_send_message` resolves `p.content = read_or_stdin(&p.content)?` before validation.
- `cmd_edit_message` calls `validate_content_size(content)?` and passes `content` directly to `buzz_sdk::build_edit`.

Searches of open and closed issues/PRs did not find this exact stdin/edit mismatch. #3022 concerns attachment preservation during edits and is unrelated.