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

Author: oschwald

README.md

@@ -112,31 +112,27 @@ See the API documentation for more details.
 
 ### Connection pooling and transport retries ###
 
-`WebServiceClient` is thread-safe and reuses a pooled `HttpClient` across
-requests. Idle connections in the pool can be silently closed by load
-balancers or other intermediaries. When the next request reuses one of these
-half-closed connections, the JDK reports the failure as a `Connection reset`,
-`Broken pipe`, or related transport `IOException`.
-
-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 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`,
+`WebServiceClient` reuses pooled HTTP connections for performance. Idle
+connections can be silently closed by load balancers or other
+intermediaries; when the next request reuses such a half-closed connection,
+the JDK reports the failure as a `Connection reset`, `Broken pipe`, or
+similar transport error.
+
+To smooth over these intermittent failures, the SDK retries once by
+default. Most transport-level `IOException`s are retried; the SDK does
+**not** retry:
+
+* **Timeouts** (`HttpTimeoutException`, including connect-phase timeouts).
+  The SDK honors the timeouts you configure rather than extending them.
+* **Cancellation** (`InterruptedIOException`, or any interrupt observed
+  before the request runs).
+* **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
-exception hierarchy. POST bodies are replayable, so retried requests are
-byte-identical to the original.
+HTTP 4xx and 5xx responses are surfaced through the existing exception
+hierarchy and are never retried. Request bodies are replayable, so retried
+requests are byte-identical to the original.
 
 You can change the retry budget via the builder: