Pass s3.part_size to the multipart uploader (closes #232)

s3.part_size was loaded and defaulted but never reached the S3 client,
whose uploader used a fixed 10MiB part. The client now takes the part
size from the config, for storage_url and for the s3.* fields, and
config load rejects a value below 5MiB or above 5GiB, the part sizes S3
accepts. The docs gave the default as 5MB, which the config file reads
as 5,000,000 bytes, below the minimum; they now say 5MiB.

Judgement call: the 5GiB maximum is enforced along with the 5MiB
minimum the issue names.
Trap: at the 5MiB default the uploader's 10,000-part limit caps one
upload at about 48.8GiB, down from about 97.7GiB; blob_size_limit is
not checked against it.

Model: opus-5-5

TODO.md

@@ -22,6 +22,15 @@ the tag exists and is exercised; what is left is merging `next` to
 
 # Completed Steps
 
+- 2026-10-07: Made `s3.part_size` set the multipart upload part size
+  ([issue #232](https://git.eeqj.de/sneak/vaultik/issues/232)). It was
+  loaded and defaulted but never passed to the S3 client, whose uploader
+  used a fixed 10MiB part. It now reaches the uploader for `storage_url`
+  and for the `s3.*` fields, and a part size S3 refuses, below 5MiB or
+  above 5GiB, fails at config load. The docs gave the default as `5MB`,
+  which the config file reads as 5,000,000 bytes, below the minimum; they
+  now say `5MiB`.
+
 - 2026-10-07: Made `remote info` stop reporting a snapshot's blobs as
   orphaned when its manifest cannot be read, and stop printing raw
   names from under `metadata/`