Unsigned `x-amz-*` request headers are honoured on presigned uploads, letting an untrusted uploader set object properties the presign never authorised

Summary

RustFS accepts and applies x-amz-* request headers that are not covered by the SigV4 signature.
On a presigned PutObject URL this breaks the guarantee the presign exists to provide: an
application hands a client a URL authorising one specific upload, and the client can additionally
set object tags, the website redirect location, and the storage class.

SigV4 requires every x-amz-* header to appear in SignedHeaders; that is the mechanism by which
a presigned URL binds what was authorised. SeaweedFS and versitygw reject the identical bytes, so
this is not inherent S3 behaviour.

Affected: rustfs 1.0.0-beta.12 (build 2026-07-30, rustfs/rustfs:latest). I did not test
earlier versions.

Details

The attacker model is the ordinary "upload direct to object storage" pattern, which is the only
reason presigning exists: the application does not trust the uploader, so it issues a narrowly
scoped, time-limited URL instead of credentials. Handing the signature to the attacker is the
design.

The presigned URL covers the method, the target key, the expiry and the signed header set. It does
not cover the extra x-amz-* headers below, and RustFS applies them anyway.

Steps to reproduce

Fresh container, fresh bucket, no prior state:

docker run -d --name rustfs -p 9004:9000 \
  -e RUSTFS_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE \
  -e RUSTFS_SECRET_KEY=wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY \
  -e RUSTFS_ADDRESS=0.0.0.0:9000 -e RUSTFS_VOLUMES=/data rustfs/rustfs:l…