Exit code 93 cannot distinguish a service being down from a service being wrong

[korya]

Split out of #24, whose documentation half is fixed. Every exit code is now in the README, the package comment and --help; this is the design half that documentation cannot address.

Problem

93 is returned for four unrelated conditions:

• connection refused
• DNS failure
• request timeout
• one or more assertions failed

The first three mean the service is unreachable. The fourth means the service answered, and the answer was wrong. Telling those apart is the distinction a monitoring tool exists to make, and a caller branching on $? cannot make it.

Why it matters

if ! http-assert --silent --assert-ok "$endpoint"; then
  page_oncall     # …for what? A dead host and a bad deploy want different responses.
fi

The README's own monitoring example has this shape. Today the only way to recover the distinction is to parse stderr, which is not a contract.

Suggested fix

Give transport failure its own code and leave 93 meaning "the response was wrong":

Code	Meaning
93	at least one assertion failed
(new)	the request never completed — refused, DNS, timeout

Client.Do already separates the two paths: the transport error returns early with failed to send request, while assertion failures accumulate and return further down. So the split is a change of return value, not of control flow.

Compatibility

This changes an exit code that scripts may branch on, so it is a breaking change for anyone treating 93 as "unreachable". Worth pairing with a note in the release that introduces it — and worth deciding whether --max-time expiry counts as transport failure or as its own thing.

Related

• Undocumented exit codes (71, 91, 2) and an overloaded 93 #24 — the documentation half, closed
• All output goes to stderr; stdout is always empty #34 — output stream separation, same theme of making results machine-consumable
• Feature: machine-readable output (--json) #45 — --json output would carry this distinction structurally