fix(buzz-cli): messages edit --content - reads stdin like send (#4361)

[iroiro147]

Problem

buzz messages send --content - reads the message body from stdin (introduced in #624), but buzz messages edit --content - signed and published 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.

Root cause

cmd_edit_message in crates/buzz-cli/src/commands/messages.rs passed the raw --content argument straight to validation and buzz_sdk::build_edit without routing it through read_or_stdin, unlike cmd_send_message (which does, at line 582).

Fix

Route the edit content flag through read_or_stdin before validation, exactly mirroring the send path. Also update the Edit::content clap help text to document the stdin convention (Use '-' to read from stdin.), matching the Send::content wording.

What was verified

• cargo check -p buzz-cli -p buzz-sdk — clean.
• cargo test -p buzz-cli --quiet — 318/318 passing (317 baseline + 1 new regression test).
• New regression test cli_edit_content_dash_is_routed_through_stdin_not_stored_literally pins the resolution expression: a bare - is a stdin sentinel, never a publishable value after resolution; non-sentinel inputs pass through verbatim.
• Functional smoke: echo 'test replacement content' | buzz messages edit --content - --event <id> now reads stdin (proceeds to the auth gate) instead of short-circuiting on the literal dash.

Fixes #4361