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

## 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` 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.