release-26.1: cloud/amazon: fix AWS_SKIP_CHECKSUM not suppressing CRC32 on multipart uploads

[blathers-crl]

Backport 1/1 commits from #166164 on behalf of @cockroach-teamcity.

---

After the aws-sdk-go-v2 s3 manager upgrade to v1.17.65, the manager's
internal initChecksumAlgorithm() unconditionally defaults ChecksumAlgorithm
to CRC32 when the field is empty. This means setting ChecksumAlgorithm = ""
on the PutObjectInput (which the code did when AWS_SKIP_CHECKSUM=true) no
longer suppresses checksums for multipart uploads — the manager overwrites
the cleared value with CRC32 before the S3 client sees it, bypassing
the RequestChecksumCalculation = WhenRequired configuration.

Fix this by adding smithy-go Initialize middleware via the Uploader's
ClientOptions that clears ChecksumAlgorithm from CreateMultipartUploadInput,
UploadPartInput, CompleteMultipartUploadInput, and PutObjectInput before
the S3 client's checksum middleware processes them. This runs after the
manager's initChecksumAlgorithm but before the client computes checksums,
effectively suppressing all checksum computation on multipart uploads when
AWS_SKIP_CHECKSUM=true.

Resolves: #166090

Release note (bug fix): Fixed a bug where the AWS_SKIP_CHECKSUM=true
storage option did not fully suppress checksums on multipart uploads
to S3-compatible storage. After an internal SDK upgrade, multipart
uploads included CRC32 checksums despite the skip flag, which could
cause errors with S3-compatible services that do not support CRC
checksums.

Generated by Claude Code Auto-Solver
Co-Authored-By: Claude noreply@anthropic.com

---

 pkg/cloud/amazon/BUILD.bazel        |  4 +++
 pkg/cloud/amazon/s3_storage.go      | 29 ++++++++++++++++++
 pkg/cloud/amazon/s3_storage_test.go | 59 +++++++++++++++++++++++++++++++++++++
 3 files changed, 92 insertions(+)

This PR was auto-generated by issue-autosolve using Claude Code.
Please review carefully before approving.

---

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.