UID2-4739: use DefaultCredentialsProvider for KMS client in JWTTokenProvider

[sophia-chen-ttd]

Summary

JWTTokenProvider explicitly constructs WebIdentityTokenFileCredentialsProvider for KMS access, which ties it to OIDC/IRSA. Switching to DefaultCredentialsProvider makes it compatible with EKS Pod Identity, instance profiles, and any future credential mechanism — matching the standard AWS SDK v2 best practice of letting the credential chain resolve at runtime.

• Replace WebIdentityTokenFileCredentialsProvider.create() with DefaultCredentialsProvider.create() in the non-static-credentials branch of getKmsClient
• Update the corresponding import

Companion fix to CloudStorageS3.java (UID2-4739).

Test plan

• Verify existing IRSA-based environments continue to work (DefaultCredentialsProvider falls through to the web identity token file provider in its chain)
• Update trust policies of EKS cluster to Pod Identity (not IRSA) and verify KMS signing succeeds
• Verify static-credentials path (accessKeyId/secretAccessKey set in config) is unchanged

🤖 Generated with Claude Code

[sophia-chen-ttd]

The swap from WebIdentityTokenFileCredentialsProvider to DefaultCredentialsProvider is correct and aligns with AWS SDK v2 best practice. The change broadens credential chain support (IRSA, EKS Pod Identity, instance profiles, env vars, etc.) without affecting the static-credentials fast-path. No functional regressions are expected, but the expanded credential chain introduces some operational subtleties worth noting.