fix(client): say which network failure happened, not just "unreachable"

[musharna]

The client caught four distinct httpx transport failures and collapsed them into one BrokerUnreachable carrying only a formatted string, so every consumer rendered identical text for two situations with opposite remedies:

• refused — something answered and said no. The path is fine; the broker is not running.
• timeout — nothing answered. The broker is probably fine; the path is not.

This came out of a live incident. On 2026-09-02 the gt76 broker was healthy (container up, listening, freshly auto-deployed to 0.5.43) while a Tailscale ACL dropped packets, because the machine had re-registered as a second, untagged node. job ping reported health: unreachable, and that was read as "the broker is down and the fleet never upgraded" — and reported that way before the host was checked.

What changed

BrokerUnreachable now carries kind (dns / refused / timeout / read_timeout / tls / network) and an operator-facing hint, classified once where the exception is caught so no consumer has to re-derive it from a message string. job ping and the main() boundary render both — the boundary previously advised "is the broker running?", which is actively wrong for a dropped packet.

job ping also stops calling a broker that answered "unreachable": a 401, a 5xx, or a non-ok body now render as "reachable, but not healthy" (exit code still 2). --json gains kind/hint, and reachable now means "the broker sent us bytes".

Real output for the incident shape:

health:  unreachable (timeout)
hint:    the connection was dropped rather than refused, which points at a firewall, a
         tailnet ACL, or routing — not at the broker. If the host answers ping but this
         port times out, the broker is likely healthy and simply unreachable from here

On the tests

They drive real sockets. The obvious ECONNREFUSED source — a closed port on 127.0.0.1 — is not portable: under WSL2 networkingMode=mirrored, IPv4 loopback to an unbound port is silently dropped while IPv6 ::1 still returns RST. A test assuming refusal there passes on normal Linux and fails on this repo's dev machine. The tests ask the kernel which family does what and skip with a stated reason, which doubles as a positive control — the probe returns an address only after observing the errno the assertion depends on.

One existing assertion required the word "unreachable" for any non-ok body; its comment described the defect rather than the intent, and is updated.

Verification

• 1351 passed (1342 baseline + 9 new), 9 deselected; ruff and mypy clean.
• Each new test watched failing first, for the stated reason.
• Mutation-verified: forcing the ConnectTimeout branch to return "refused" reddens only the two timeout tests and leaves the refused test green, proving the paths are discriminated independently rather than keyed off one branch. Reverting reachable to error is None reddens only the 401 test.
• Operator output read by hand for DNS, refused, and dropped-SYN, not just asserted on.