RetryingHttpClient.close skips sleeper cleanup when delegate close fails

Description

RetryingHttpClient owns both its delegate HttpClient and Sleeper, but closes them sequentially:

override fun close() {
    httpClient.close()
    sleeper.close()
}

If httpClient.close() throws, sleeper.close() is never attempted.

This can leak sleeper-owned resources. The default sleeper owns a Timer, and custom sleepers may own executors or other lifecycle state.

The repository already uses a failure-preserving close pattern in AuthenticatingHttpClient: always attempt both owned cleanups, propagate the first failure, and attach a distinct second failure as suppressed.

Expected behavior

RetryingHttpClient.close() should always attempt to close both owned resources.

If both fail, the delegate failure should remain primary and the sleeper failure should be attached as suppressed. If only the sleeper fails, that failure should propagate normally.

Regression coverage

• delegate close failure still closes the sleeper;
• both close failures preserve the delegate failure and suppress the sleeper failure;
• sleeper-only failure propagates;
• normal close closes both resources.

Start by locating RetryingHttpClient and its close() implementation, then compare it with the failure-preserving close pattern in AuthenticatingHttpClient. Add regression coverage for delegate-only failure, both failures, sleeper-only failure, and normal cleanup; done means both resources are always attempted and failures are propagated as specified.