WorkloadIdentityHttpClient can leak its delegate when auth cleanup throws

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.

Start by locating WorkloadIdentityHttpClient.close() and compare its cleanup flow with the sibling AuthenticatingHttpClient pattern. Add regression coverage for auth failure with delegate cleanup, failures from both resources with suppression, and normal cleanup; done means both resources are attempted and the first failure is preserved.