release-26.2: cloud/amazon: retry s3 requests on credential-expiry errors

[dt]

Backport 1/1 commits from #169763 on behalf of @dt.

---

When the configured credentials provider issues short-lived tokens, a long-running operation that issues many concurrent multipart UploadPart calls can race the credential expiry: a request signed just before the credentials expire can arrive at S3 just after, and S3 returns ExpiredToken / ExpiredTokenException / RequestExpired.

aws-sdk-go v1 swallowed this race by classifying these three codes as retryable in its default retryer (see credsExpiredCodes folded into isCodeRetryable, plus the matching post-attempt cache invalidation in
the after-retry handler which calls Credentials.Expire() between attempts). aws-sdk-go-v2's standard retryer ships DefaultRetryableErrorCodes containing only RequestTimeout / RequestTimeoutException, so what was a transparent retry in v1 became a hard, user-visible failure when CRDB migrated to v2.

This commit restores the v1 behavior for the s3 client by wrapping the standard retryer with retry.AddWithErrorCodes for the same three codes v1 used. The cache-invalidation half from v1 is not separately needed in practice: by the time the retry's backoff completes, local time has advanced past the cached credentials' `Expires`, so the cache's IsExpired check on Retrieve forces a fresh retrieve on the next signing pass on its own.

The aws_kms.go retryer has the same gap and could be addressed in a follow-up; this commit keeps the s3 fix isolated for ease of backporting to release branches.

Release note (bug fix): A long-running BACKUP to s3 using AUTH=implicit no longer fails with an ExpiredToken error when it races the rotation of the underlying short-lived credentials; the s3 client now retries ExpiredToken, ExpiredTokenException, and RequestExpired the same way the legacy aws-sdk-go v1 client did.

---

Release justification:

[blathers-crl]

Thanks for opening a backport.

Before merging, please confirm that the change does not break backwards compatibility and otherwise complies with the backport policy. Include a brief release justification in the PR description explaining why the backport is appropriate. All backports must be reviewed by the TL for the owning area. While the stricter LTS policy does not yet apply, please exercise judgment and consider gating non-critical changes behind a disabled-by-default feature flag when appropriate.

[trunk-io]

😎 Merged successfully - details.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is