Narrow the replay errno set to failures that prove no connection existed

`CONNECT_CODES` drives `isSafeToReplay`, which is the only thing standing
between a transport failure and a replayed `POST /users/two-factor/verify`.
It included `EHOSTUNREACH`, `ENETUNREACH` and `ENETDOWN` on the stated
grounds that those errnos can only be reported before any request byte was
written. That is not true on Linux: an ICMP destination-unreachable
delivered on an already-established connection sets the socket error and
the next read or write returns `EHOSTUNREACH` or `ENETUNREACH`, and a local
interface going down after the request was fully written surfaces as
`ENETDOWN` the same way. In each case the server may already have received
and acted on the request -- exactly the ambiguity the rule exists to
exclude, on the paths that consume a second-factor attempt or register a
thumbnail.

The three are dropped from `CONNECT_CODES` and stay in `TRANSPORT_CODES`,
so they remain retryable for the idempotent calls; only replay eligibility
narrows. What is left -- `ENOTFOUND`, `EAI_AGAIN`, `ECONNREFUSED` -- means
no TCP connection to the server ever existed, so no request byte can have
been transmitted.

The justification is corrected everywhere it was stated: the comment on
`CONNECT_CODES`, the one on `isSafeToReplay`, the `postJSON` call site, the
README's idempotency section and the `client.test.ts` docblock. All of them
now describe what the narrowed set actually establishes rather than
claiming a proof it did not support.

The narrowing is enforced by the suite rather than asserted in a comment:
the three errnos join `ECONNRESET`/`EPIPE`/`ETIMEDOUT` in the
`isSafeToReplay`-returns-false test, with companion `isRetryable` assertions
so a future edit cannot make them non-retryable by accident. Putting the
three back into `CONNECT_CODES` turns that test red (1 failure, verified).

README.md

@@ -305,12 +305,18 @@ only guarded the initial request would leave the same hang one layer down.
 **Non-idempotent requests are not blindly replayed.** `postJSON` and `putJSON`
 reach `/users/srp/create-session`, `/users/two-factor/verify` — which consumes
 one of a small number of second-factor attempts — and `/files/thumbnail`. They
-are retried only on failures that prove no request byte reached the server,
-which means the connection was never established (`ECONNREFUSED`, `ENOTFOUND`,
-and the like). A 5xx, a mid-flight reset and a deadline are all left to the
-caller, because each of them can happen after the server has already acted.
-`putFile` is exempt: a presigned PUT stores one whole object at one key in one
-request, so replaying it has no partial state to damage.
+are retried only on the three failures that establish no TCP connection to the
+server ever existed, so no request byte can have been transmitted: `ENOTFOUND`
+and `EAI_AGAIN` (name resolution produced no address) and `ECONNREFUSED` (the
+peer refused the connection). A 5xx, a mid-flight reset and a deadline are all
+left to the caller, because each of them can happen after the server has already
+acted. The routing errnos `EHOSTUNREACH`, `ENETUNREACH` and `ENETDOWN` are
+excluded for the same reason, despite looking like connect-time failures: on
+Linux an ICMP unreachable arriving mid-flight, or a local interface going down
+after the request was written, delivers them on an already-established socket.
+They stay retryable for the idempotent calls. `putFile` is exempt: a presigned
+PUT stores one whole object at one key in one request, so replaying it has no
+partial state to damage.
 
 A download is retried as a whole — request, stream consumption, and decryption —
 because a socket reset after the response headers have arrived surfaces in the