v2-platform: 03 R2/S3 storage provider + hardening + dual domains

Parent

#274 (v2 platform services spec)

What to build

The real storage provider: S3-compatible PUTs (aws4fetch) with scoped, service-held tokens behind the storage adapter seam. Explicit content-type map and immutable cache-control on content-hashed paths (the failure mode that stalled the earlier Cloudflare attempt must be impossible). Day-one hardening: streaming (non-buffering) uploads, concurrency cap, per-account size and file-count quotas, MIME allowlist, robots noindex. Two serving domains: the member domain for account-namespaced uploads, the official domain for platform-account CI uploads through the same service — only the service ever holds CDN credentials.

Acceptance criteria

• Uploaded bundles are fetchable from the member domain with correct content-type and immutable cache-control headers (stylesheets serve as text/css)
• Re-uploading identical content dedupes (same content-hash path, no duplicate storage)
• Over-quota, over-count, disallowed-MIME, and concurrent-flood uploads are all rejected cleanly
• Uploads stream without buffering whole bundles in service memory
• Official-path uploads land under the platform account on the official domain through the same contract
• Member-domain responses carry noindex headers
• Scoped S3 tokens — no account-wide credentials in any plugin environment

Blocked by

• #275 (deploy service core)

Start with the v2 platform services spec in #274 and the deploy service core in #275, then trace the storage adapter seam described here. Review the aws4fetch integration and map each acceptance criterion to an implementation or test location. Done means the provider satisfies the upload, quota, streaming, deduplication, domain, header, and credential-isolation criteria.