CLI: buzz moderation reports --status silently returns empty for invalid values

Start with ModerationCmd::Reports in crates/buzz-cli/src/lib.rs and cmd_reports in crates/buzz-cli/src/commands/moderation.rs; compare their argument handling with PatchesCmd::Status and feed get --types. Reproduce the invalid-status command, then verify that unknown values are rejected with CliError::Usage before any request while the four documented statuses still work.

Describe the bug

buzz moderation reports --status opne (typo) prints [] and exits 0. That is indistinguishable from “the queue is empty.” A moderator or agent that meant --status open can miss real open reports.

Help text documents four values (open | resolved | dismissed | escalated) but nothing enforces them. The status string is appended to the query as-is. The DB filter is status = $2, so an unknown token matches zero rows and looks like success.

This is the same fail-open class as #6945 (messages get --kinds): invalid CLI input must not look like a successful empty result. Agents cannot inspect stderr interactively.

Steps to reproduce

1. With a relay that has at least one open report, run:
   buzz moderation reports --status open
   Observe: open reports are returned.
2. Run:
   buzz moderation reports --status opne
3. Observe: [], exit code 0.
4. Same with --status pending, --status OPEN, --status "open ".

Expected behavior

Exit 1 with CliError::Usage, naming the bad value, e.g.
invalid status "opne" — must be one of: open, resolved, dismissed, escalated

Actual behavior

The invalid status is forwarded to GET /moderation/reports?status=opne. The SQL is WHERE … ($2::text IS NULL OR status = $2), so unknown status returns an empty list with no error.

Version and platform

• Buzz CLI: current main
• OS: any

Logs / additional context

crates/buzz-cli/src/commands/moderation.rs (cmd_reports) — no validation; status is interpolated into the path.

crates/buzz-cli/src/lib.rs (ModerationCmd::Reports) — status: Option<String> with no value_parser. Contrast PatchesCmd::Status, which uses value_parser = ["open", "merged", "closed", "draft"], and feed get --types, which rejects unknown tokens before the query.

crates/buzz-db/src/moderation.rs (list_reports) — equality filter, not an enum check.

Suggested fix

Validate before the request (clap value_parser or an explicit allow-list in cmd_reports) and return CliError::Usage on the first unknown value. Do not send the request.