fix(cli): make 'buzz messages edit --content -' read stdin like send

[kushaim]

Fixes #4361.

cmd_edit_message validated and signed the literal "-" as the
replacement body when callers passed --content -, while
cmd_send_message correctly resolves stdin in the same situation
(introduced in PR #624). The two paths diverged in this one step.

This is hazardous for agents: an agent can 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.

Mirrors cmd_send_message's exact pattern: read stdin if -, then
validate the resolved content, then pass the resolved string to
build_edit. No new public API, no behavior change for non--
content, no change to cmd_send_message.

Includes a regression test on the read_or_stdin helper
(read_or_stdin_dash_reads_stdin_not_literal_dash) that asserts
read_or_stdin("-") is not the literal "-". A test runner's
stdin is empty, so the result is Ok("") — the test is robust
against whatever the runner has on stdin as long as it isn't a
literal "-" (which would itself be a bug).

Verified:

• cargo check -p buzz-cli --lib — clean
• cargo test -p buzz-cli --lib — 318 passed, 0 failed (the new
  test included)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.