fix(s3): multipart uploads for large and streaming bodies

[wolfy-j]

Problem

cloudstorage.UploadObject (S3 backend) sent the body through a single s3.PutObject. Against S3-compatible stores this fails for large or streaming bodies:

• A non-seekable reader with no Content-Length returns 411 MissingContentLength.
• A large body signed as one aws-chunked stream is rejected by MinIO once a chunk exceeds 16MiB: chunk too big: choose chunk size <= 16MiB.

The Lua cloudstorage:upload_object path hands UploadObject a plain io.Reader (string bodies wrap bytes.Reader; userdata bodies pass the raw reader), so any multi-gigabyte checkpoint or dataset upload fails.

Fix

Route UploadObject through the SDK multipart manager (feature/s3/manager) with a 16MiB part size. The manager buffers the stream into parts of known length, so:

• unbounded / non-seekable streams upload without a caller-supplied Content-Length;
• no single request carries an aws-chunked chunk larger than MinIO's 16MiB cap;
• objects split into up to 10000 parts (160GiB for unknown-length streams; auto-grown up to S3's object max for known-length bodies).

All existing PutObjectInput semantics are preserved (content-type, cache-control, disposition, encoding, metadata, If-Match/If-None-Match, and the custom request-header middleware, now applied via Uploader.ClientOptions); the ErrPreconditionFailed mapping is unchanged.

Test

TestUploadObjectLargeStream uploads a 32MiB non-seekable stream and reads it back byte-identical. It is gated on S3_ENDPOINT/S3_ACCESS_KEY/S3_SECRET_KEY (skips without a live endpoint). Verified against a live MinIO: fails on the pre-fix code (411 MissingContentLength), passes after.