fleet dispatch status silently ignores all arguments — --help performs a live GET /health and typos are swallowed #5560

Bug: fleet dispatch status silently ignores all arguments — --help performs a live GET /health instead of printing help, and typos are swallowed

pkgs/fleet/crates/fleet-dispatch/src/lib.rs (new in step 4, #5432):

• run() routes the verb and discards the rest of argv for status:

Some("status") => verb_status(config),

• verb_status(config) takes no argument list at all — it unconditionally
  picks a transport and exchanges GET /health.
• Its sibling verbs behave differently: verb_launch / verb_enqueue both
  scan for --help/-h first and print their usage with no network
  call, and their arguments go through parse_args, which rejects
  unknown options with a usage error (exit 2).

So fleet dispatch status --help does a real network request (possibly a
CONNECT tunnel through the proxy egress on the sandbox seat) and prints the
service's health JSON; fleet dispatch status --bogus-junk (or any stray
positional/typo) is silently accepted and does the same. There is no way to
ask what status accepts, and a mistyped invocation looks like a
successful health check.

Verified this run (laptop probe, real crate @ main 7cd293e)

Probe crate ~/git/fleet/probe-dispatch-status (path-dep on the real
fleet-dispatch) calling fleet_dispatch::run with
[dispatch] url = http://127.0.0.1:48931 pointed at a fake pm-dispatch
server that logs requests and returns {"ok":true,"build":"probe"}:

• Case 1 — status --help: printed the health JSON + transport line,
  exit 0; server log shows GET /health. No help text.
• Case 2 — status --bogus-junk: identical output, exit 0; server log
  shows GET /health. The unknown argument was never rejected.
• Case 3 — control, status: same output, exit 0, GET /health
  (correct behavior).
• Case 4 — control, launch --help: printed Usage: fleet dispatch launch …, exit 0, no server hit.

Server log after all four cases: exactly three GET /health lines
(cases 1–3).

Why it matters

• Same bug class as fleet: serve <role> --help (and the queue-broker/secrets-broker argv0 aliases) starts the daemon instead of printing help #5488 (serve <role> --help starting the daemon):
  a help flag that triggers real work instead of printing help erodes the
  CLI contract the fleet multicall is built around (§3: help is always
  available, never has side effects).
• Silently ignored arguments hide operator typos — e.g. an intended
  filter/limit flag on a status check appears to succeed, so scripts and
  humans trust output for a different invocation than the one they typed.

Acceptance criteria

• fleet dispatch status --help (and -h) prints a status usage
  text and performs no network request, mirroring
  launch/enqueue.
• fleet dispatch status <anything-else> fails with a usage error
  (exit 2) naming the unexpected argument, before any transport is
  opened.
• Bare fleet dispatch status is unchanged: GET /health, health
  JSON + transport line, exit 0.
• Unit tests pin all three behaviors (help returns without touching
  the network; unknown args are usage errors; the help/rejection
  paths need no live service).
• cargo test -p fleet-dispatch green.