Define a sensible S3 API subset for the spike

[alanshaw]

We need an explicit, written, testable answer to "which slice of the S3 API is ms3t targeting for the initial spike?" Without this, smoke tests and telemetry instrumentation have nothing to bind to.

Prior art

• cloud-portable/storage tier 1 RFC. Proposed as our "good enough for now" target — a coherent minimal subset designed for portability.
• ceph/s3-tests. Industry-standard conformance suite. Proposed as our success metric — see Acceptance.

Current ms3t-supported surface

Per storacha/sprue#34:

• Bucket CRUD (create, list, head, delete)
• Object PUT, GET, HEAD, DELETE
• ListObjectsV2
• Range GETs
• Path-style addressing only
• No multipart, no aws-chunked, no SSE, no pre-signed URLs, no AWS Sig V4, no x-amz-meta-*, no versioning/object-lock

Out of scope here, but tracked as gap

The FilOne on-ramp requirements list AWS Sig V4, multipart upload, pre-signed URLs, SSE, x-amz-meta-*, versioning, and object lock as hard requirements. They are deferred until the tenant management spike proposes a sequencing. This issue should enumerate the gap, not close it.

Acceptance

• A markdown doc lands in enumerating in-scope operations + headers + auth modes for the spike, with explicit references to cloud-portable/storage tier 1 if helpful.
• The doc names the subset of ceph/s3-tests we consider in-scope and the subset we consider out-of-scope-for-now (with reasons).