Default new uploads to S3 Intelligent-Tiering storage class

Proposed change

When the CLI uploads objects to S3, set StorageClass: INTELLIGENT_TIERING by default on:

• PutObject requests
• CreateMultipartUpload requests (this is where storage class is set for multipart — not on individual UploadPart calls; easy to miss in review)

Add a --storage-class flag (and corresponding env var, e.g. SOURCE_COOP_STORAGE_CLASS) that lets users override the default. Default value: INTELLIGENT_TIERING.

--storage-class is the standard AWS CLI flag name on s3 cp / s3 sync and the standard StorageClass field in the AWS SDKs, so plumbing through should be straightforward.

Accepted values (validate against this allowlist; reject others with a clear error):

Glacier-tier classes (GLACIER_IR, GLACIER, DEEP_ARCHIVE) are intentionally not supported in this initial release. They have meaningful operational implications — retrieval fees, retrieval latency, separate user expectations for cold data — that we want to design proper support around (UX for restore requests, documentation, possibly publisher-facing tooling) before exposing them. We'll add them in a follow-up once that work is scoped.

Other classes (ONEZONE_IA, STANDARD_IA, REDUCED_REDUNDANCY, EXPRESS_ONEZONE, OUTPOSTS, SNOW) are out of scope: either inappropriate for a durable public archive, deprecated, or not applicable to Source's deployment.

Acceptance criteria

• Single-part uploads default to INTELLIGENT_TIERING.
• Multipart uploads default to INTELLIGENT_TIERING (set on CreateMultipartUpload).
• --storage-class flag overrides the default and accepts the standard S3 storage class names.
• Behavior is documented in the CLI's README / --help output, including the rationale (cost) so users understand what the default does.
• Released and available via the standard install path (homebrew tap + GitHub releases) by April 30, 2026.

Why the date

We want May 2026 to be a clean month of billing data that reflects the optimized state. With both the bucket lifecycle rule and the CLI default in place by April 30, the May AWS bill will be the first full month under the new configuration, which gives us a clean before/after comparison against the Nov 2025 – Apr 2026 baseline.

Notes / things to verify

• Confirm whether the CLI uses the AWS SDK or shells out to aws s3 cp / aws s3 sync. If it shells out, plumbing --storage-class through is sufficient. If it uses the SDK directly, set on the relevant request structs.
• The 30-day minimum storage charge for Intelligent-Tiering means objects deleted within 30 days of upload still incur the 30-day charge. This is essentially a non-issue for a public archive but worth a one-line note in the docs.
• We are not adding a bucket policy that requires the storage class header. Web UI uploads, browser-based uploads via presigned URL, and stock-SDK clients should continue to work; the lifecycle rule will catch them server-side.

Start by locating the CLI upload entry points and checking whether they use AWS SDK PutObject/CreateMultipartUpload calls or invoke aws s3 commands. Trace the storage-class flag and environment configuration, then verify single-part and multipart behavior, accepted-value errors, README/help documentation, and the standard release path.