feat(upload): stamp backend-vended metadata onto uploaded objects

[ben-miru]

Summary

• The backend's create-upload response (UploadWithCredentials) vends a metadata map carrying object provenance (e.g. device_id, release_id, digest); the agent previously dropped it, so uploaded objects landed in the bucket without it. This threads the map generically — no key inspection — from the create-upload response through the ObjectTransfer seam onto the wire.
• s3::Store stamps the map as x-amz-meta-* headers on PutObject and CreateMultipartUpload (parts/complete and resumed uploads inherit from initiation per S3 semantics); gcs::Store stamps it as custom object metadata in the object-resource JSON. An empty map adds no headers, keeping requests byte-identical to before.
• Nothing is persisted in the job queue: a retried job mints a fresh upload and receives an equivalent map from the backend.
• Integration tests assert the metadata lands on the wire for S3 single-part, S3 multipart, and GCS, plus an end-to-end test driving a mocked create-upload response through the production SdkTransfer against replayed S3.

Plan: plans/completed/20260717-store-upload-metadata.md

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}