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

[hardy4yooz]

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:

   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:

   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.

[FabianHertwig]

Still reproduces on main at eed74bde2f4797714335ac10c56c0b0244c1def4: cmd_edit_message passes --content straight through, while cmd_send_message resolves it via read_or_stdin.

Two things that make this worse in practice for agents:

1. The CLI returns accepted: true with a new event id, and buzz messages get does not show edits — so the usual self-check cannot detect the failure. The message silently becomes -.
2. The same mismatch exists in buzz social publish (buzz social publish treats --content - literally, returns accepted, and cannot delete the bad note #4905), so this is a per-command convention rather than a shared one. A shared helper applied to every content-bearing write would fix the class instead of one command.

Two open PRs (#4364, #4684) have been waiting for review since early August.