fix(auth): avoid redundant retrieveSubjectToken call in AwsCredentials with service account impersonation

[lsirac]

Summary

When service account impersonation is configured on AwsCredentials, refreshAccessToken() previously called retrieveSubjectToken() on the outer credential before exchangeExternalCredentialForAccessToken() delegated to impersonatedCredentials.refreshAccessToken(). This queried the AWS metadata server or AwsSecurityCredentialsSupplier twice and discarded the first signed GetCallerIdentity subject token.

AwsCredentials.refreshAccessToken() now checks getServiceAccountImpersonationUrl() != null and delegates directly to this.impersonatedCredentials.refreshAccessToken(), reusing the cached impersonatedCredentials instance across refreshes.

Testing

• Unit tests: AwsCredentialsTest and ExternalAccountCredentialsTest (91 tests passing)
• Live end-to-end manual testing with real AWS EC2 IMDSv2 temporary security credentials (byoid-test IAM role in AWS account 077071391996, us-east-2) against byoid-pool/providers/aws-pid2 on sts.googleapis.com, iamcredentials.googleapis.com, oauth2.googleapis.com/tokeninfo, and pubsub.googleapis.com: https://paste.googleplex.com/4757180109160448

[gemini-code-assist]

Code Review

This pull request updates AwsCredentials to reuse cached impersonated credentials during access token refreshes, preventing redundant AWS metadata queries when the source STS token is still valid. The test suite has been updated to assert correct request counts and verify caching behavior. A review comment suggests simplifying the implementation in AwsCredentials by delegating directly to super.refreshAccessToken() instead of duplicating the lazy initialization and delegation logic.