feat: add host-provided module object storage

`manifest.storage.buckets` has existed since manifest version 1 and meant
nothing — discovery validated it and no code read it. This turns it into a
real capability, which is what stands between Announcements and the module
system: that product currently fetches a hardcoded LAN S3 endpoint, parses
ListObjectsV2 XML by hand, and hands the browser direct object URLs.

- A module declares a logical bucket and receives a scoped facade at
  `context.storage` — list, head, get, put, delete. The contract names no
  provider: no endpoint, region, credential, or physical bucket is reachable
  from it, which is what lets the same module run under a future standalone
  host over its own or a shared S3-compatible service.
- Core's first provider speaks S3 through the AWS SDK. SeaweedFS is the
  deployment target (ADR 0004), never an API name. Probing the pinned image
  found `CreateBucket` reporting `BucketAlreadyExists` rather than AWS's
  `BucketAlreadyOwnedByYou`; treating only the AWS spelling as success would
  have failed every second boot. A live test pins it.
- Logical → physical mapping is deterministic and collision-safe: an
  installation prefix, the module and bucket ids joined by `--` (which cannot
  occur inside either identifier, so `a-b`+`c` and `a`+`b-c` cannot collide),
  and a digest over the full untruncated identity. Two modules declaring
  `assets` always get separate namespaces; neither can see the physical name.
- Declaring a bucket is now a requirement: with no provider configured the
  module is `blocked · storage_unavailable` through ADR 0028's existing
  resolver, propagating to required dependents. An installation with no object
  storage stays a complete deployment.
- Binding availability is not provider health. Eligibility asks whether
  storage is configured, never whether it answered; bucket creation is lazy on
  first use so a storage outage cannot stop the platform booting; a running
  module whose store blinks stays running and retries. Nothing deletes a
  bucket.
- Credentials are deployment-supplied, never persisted, never routed through
  module configuration, and never visible to modules, module UI, diagnostics,
  or API responses. Provider errors translate to a closed code set carrying no
  endpoint, bucket, request id, or XML.
- Retires ADR 0029's transitional `bucket` configuration key. No manifest
  version change. The template declares no bucket, so it still runs without S3.

See ADR 0030.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/development/testing.md

@@ -193,6 +193,29 @@ rejected without touching `Object.prototype`, and a module blocked by its own co
 from the mountable UI inventory exactly like a disabled one. See
 [ADR 0029](../architecture/decisions/0029-module-configuration-and-secrets.md).
 
+A seventh dedicated suite (`core/tests/module-storage.integration.ts`, included in the same
+`pnpm test:migrations:integration` run) proves the object-storage contract against a **real
+S3-compatible server** — the SeaweedFS service the repository's Compose file already pins, brought up
+alongside PostgreSQL by the same harness, so this adds no new CI infrastructure.
+
+It exists because mocking would have hidden a real divergence: probing the pinned SeaweedFS 4.28 image
+directly showed that `CreateBucket` on an existing bucket reports `BucketAlreadyExists`, **not** AWS's
+`BucketAlreadyOwnedByYou`. A provider treating only the AWS spelling as success would have failed on
+every second boot against this repository's own development storage, and no unit test would have
+caught it. The suite pins that idempotency, plus a real round trip with content type and unquoted
+ETag preserved, streaming a body without buffering, a Web stream going straight into a `Response`,
+prefix listing and real pagination, a missing object mapping to a structured not-found error carrying
+no endpoint or XML, two modules declaring the same logical bucket staying genuinely isolated on one
+server, the longest bucket name the mapping can produce being accepted, a real connection failure
+mapping to `STORAGE_PROVIDER_UNAVAILABLE`, and a bucket surviving the deletion of every object in it.
+
+Unit suites (`core/tests/module-storage.test.ts`, `core/tests/module-storage-lifecycle.test.ts`) use an
+injected in-memory provider and never touch the network. They prove the parts the protocol cannot:
+binding determinism and collision-safety, scoping and cross-module isolation, key validation, lazy
+provisioning and retry-after-failure, configuration validation and credential redaction, and the
+lifecycle integration including dependency propagation. See
+[ADR 0030](../architecture/decisions/0030-host-provided-module-object-storage.md).
+
 ### Which kind of timing proof lives where
 
 Pass 4 introduced several deadlines, and their tests deliberately differ in kind: