fix: preserve artifact tags in multipart uploads

[mfroembgen]

Summary

• pin the exact immutable rust-s3 fix from Preserve headers in multipart stream uploads durch/rust-s3#471
• add application-level regression coverage below, at, and above the 8 MiB multipart boundary
• keep artifact uploads streaming and preserve the existing signed-cache GET behavior

Root cause

The storage layer already passes x-artifact-tag as S3 user metadata. rust-s3 0.37.2 applies those per-upload headers to single-part PutObject, but does not forward them to CreateMultipartUpload once the first chunk reaches 8 MiB. S3 metadata must be supplied during multipart initiation.

The linked rust-s3 change forwards streaming-builder headers to initiation using a request-scoped bucket clone. Existing public APIs, multipart parts/completion, bounded concurrency, error propagation, and credential-provider behavior remain unchanged.

Verification

• cargo fmt --all -- --check
• RUSTFLAGS=-Dwarnings cargo clippy
• cargo test --all-features (11 unit tests and 18 end-to-end tests)
• cargo build --release --locked
• Linux ARM64 container build; the existing builder also produced both ARM64 and AMD64 Linux binaries
• Tokio and async-std rust-s3 MinIO boundary regressions

Released 4.0.13 behavior:

Size	PUT	Stored metadata	GET x-artifact-tag
8,388,607	201	present	present
8,388,608	201	missing	missing
8,715,039	201	missing	missing

Final scratch container against MinIO:

Size	PUT	Stored metadata	GET x-artifact-tag
8,388,607	201	present	present
8,388,608	201	present	present
8,715,039	201	present	present

Dependency coordination

This draft pins the full immutable commit from durch/rust-s3#471 so it can be tested end to end. It should move to a released rust-s3 version, or another maintainer-approved immutable upstream reference, before becoming ready to merge.

Fixes #620