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).

src/api/client.ts

@@ -227,11 +227,12 @@ export class ApiClient {
         // Idempotency: this reaches `/users/srp/create-session`,
         // `/users/two-factor/verify` and `/users/ott`, all of which change
         // server state — verifying a second factor consumes one of a small
-        // number of attempts. So a POST is replayed only when the failure
-        // proves the request never reached the server, which in practice means
-        // the connection was never established. A 5xx, a mid-flight reset and
-        // a timeout are all left to the caller, because each of them can occur
-        // after the server has already acted.
+        // number of attempts. So a POST is replayed only on a failure that
+        // establishes no TCP connection to the server ever existed: DNS
+        // produced no address, or the peer refused the connection. A 5xx, a
+        // mid-flight reset, a routing errno (which Linux also delivers on an
+        // established socket) and a timeout are all left to the caller,
+        // because each of them can occur after the server has already acted.
         return withRetry(
             async () => {
                 const resp = await this._fetch(url, {