fixup! STF-322: Document transport-failure retry in README and CHANGELOG

Author: oschwald

CHANGELOG.md

@@ -4,12 +4,8 @@ CHANGELOG
 5.0.3 (unreleased)
 ------------------
 
-* Added `WebServiceClient.Builder.maxRetries(int)` to configure transport-
-  failure retry behavior. Defaults to 1 (one retry on transient transport
-  errors such as connection reset, broken pipe, EOF, or closed channel).
-  Set to 0 to disable. `HttpTimeoutException` (covering both request-phase
-  and connect-phase timeouts), `InterruptedIOException`, and HTTP 4xx/5xx
-  responses are never retried.
+* Added `WebServiceClient.Builder.maxRetries(int)` to bound transport-failure
+  retries (default 1; set 0 to disable). See the README for retry semantics.
 
 5.0.2 (2025-12-08)
 ------------------

README.md

@@ -82,13 +82,18 @@ half-closed connections, the JDK reports the failure as a `Connection reset`,
 
 To smooth over these intermittent transport failures, the SDK retries once
 by default. Any transport-level `IOException` raised by the underlying HTTP
-send is retried, with two exceptions:
+send is retried, with the following exclusions:
 
 * `HttpTimeoutException` — a request-phase timeout. Connect-phase timeouts
   (`HttpConnectTimeoutException`) are also excluded because they extend
   `HttpTimeoutException`. The SDK honors the timeouts you configure.
 * `InterruptedIOException` — the calling thread was interrupted; the SDK
   honors the cancellation rather than override it.
+* Typically deterministic failures: `UnknownHostException`,
+  `ConnectException`, `SSLHandshakeException`, `SSLPeerUnverifiedException`.
+  Retrying these would just delay surfacing a config bug.
+* If the calling thread is already interrupted when the predicate runs, the
+  retry is short-circuited regardless of the exception type.
 
 HTTP 4xx and 5xx responses are not retried — they are returned as
 `HttpResponse` objects (not `IOException`s) and surfaced through the existing