`check` exit codes (0/1/2) are not documented — operators can't write reliable wrappers/runbooks

[dolph]

Operability problem

connectivity check returns three different exit codes, but only one is documented and only in passing:

• connectivity.go:48-52: os.Exit(0) on success, os.Exit(1) on at-least-one-unreachable.
• connectivity.go:123: os.Exit(2) when destination parsing fails.
• connectivity.go:31-34: log.Fatal(err) (exit code 1) when no config file is found.
• connectivity.go:91: os.Exit(2) on invalid subcommand.
• connectivity.go:81: os.Exit(2) on invalid help subcommand.

The only place this is hinted at to users is help.go:77 in validate-config's help text: "Any validation errors will produce a non-zero return code (1)." — and that's actually a lie, because parse errors return 2.

The README and connectivity help check do not document exit codes at all.

Concrete operator confusion

"My runbook wraps connectivity check in a bash script: if ! connectivity check; then page; fi. We just got paged because someone deleted /etc/connectivity.yml during a config migration. Should that page have fired? Was the destination actually unreachable, or did the tool fail to start? I can't tell from the exit code without reading the source."

"I want to distinguish 'destination is down' (exit 1, page) from 'config is broken' (exit 2, alert the deployment pipeline). But check returns 1 for 'no config' and 1 for 'unreachable', and 2 for both 'parse failure' and 'unknown subcommand'. So I can't reliably branch."

Suggested fix

1. Document the exit codes in the help check, help wait, help monitor, help validate-config output and in the README.
2. Make them consistent:
   • 0: success
   • 1: connectivity failure (the network thing being measured failed)
   • 2: usage error (bad CLI arg, unknown subcommand)
   • 3: configuration error (missing/malformed config, parse failure)
3. Fix the misleading copy in help.go:77 (validate-config claims exit 1 but actually exits 2 via ParseDestinations).

This is bug-class (the documented behavior doesn't match the implementation) and operability (the operator's runbook depends on it).