WorkloadIdentityHttpClient can leak its delegate when auth cleanup throws #882

Description

WorkloadIdentityHttpClient.close() currently closes workloadIdentityAuth before closing its delegate:

override fun close() {
    workloadIdentityAuth?.close()
    delegate.close()
}

If the configured workload-identity provider throws from close(), execution never reaches delegate.close().

This differs from the sibling AuthenticatingHttpClient, which deliberately attempts both cleanup operations and preserves the first failure while suppressing a second one.

Impact

A custom SubjectTokenProvider may implement AutoCloseable and fail during cleanup. In that case the underlying HTTP client can remain open, retaining transports, connection pools, executors, or other resources.

Expected behavior

Closing the wrapper should always attempt to close both owned resources. If both fail, the first failure should be propagated and the second retained as a suppressed exception.

Suggested fix

Use the same failure-preserving cleanup pattern already used by AuthenticatingHttpClient, with workload-identity cleanup attempted first and delegate cleanup guaranteed afterward.

Add regression coverage for:

• auth cleanup fails, delegate still closes;
• both cleanup operations fail, delegate failure is suppressed on the auth failure;
• normal close still closes both resources.