Bootstrap S3 facade: HTTP listener + MST + Forge integration

[alanshaw]

Prototype the smallest thing that makes a real S3 client talk to a real Forge stack and round-trip data correctly.

Status: IN FLIGHT — see #34

PR #34 implements:

• An S3-compatible HTTP listener (pkg/ms3t/server/) gated by config.MS3T.Enabled, separate listener from sprue's UCAN endpoint
• A bucket-as-MST data model (forked from atproto MST in pkg/ms3t/mst/)
• Object body chunking + manifest blocks
• One CAR per S3 op (body + manifest + mutated MST nodes), uploaded via sprue's existing piriclient / routing / indexerclient in-process
• A SQLite-backed bucket → MST root registry (pkg/ms3t/registry/)
• Self-issued UCAN delegations from a generated did:key space identity
• Smelt-deployed forge.no_cache mode (synchronous writes, no read cache)

See storacha/sprue#34 for design notes, the alternatives considered, and open questions for the team.

Decisions baked in (re-litigate later if needed)

• In-process integration (not "pass a guppy client") — chosen to inherit sprue's identities + clients without protocol overhead. The long-term integration in guppy is not in this epic's scope; it would be a future spike.
• Sync writes, no local block cache — closes the read-after-write race by construction. The alternative Batched mode exists in code but is not wired in the deployed config.
• ms3t owns its space — generates its own keypair, is its own UCAN root authority. Up for change once we have a real tenant model.

Acceptance

• HTTP listener serves the operations enumerated in the API subset issue against a real Forge stack in smelt
• PR #34 merged? I don't know if this is what we want yet, or a feature branch.
• Architectural doc landed and linkable