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]>

scripts/test-migrations-integration.sh

@@ -67,8 +67,13 @@ if ! "${compose[@]}" config --quiet >/dev/null 2>&1; then
   echo "PostgreSQL migration test infrastructure configuration is invalid." >&2
   exit 1
 fi
-if ! "${compose[@]}" up --detach --wait --wait-timeout 120 postgres >/dev/null 2>&1; then
-  echo "Disposable PostgreSQL did not become ready." >&2
+# PostgreSQL and the S3-compatible object-storage service are both brought up from the repository's
+# own pinned Compose file, so the live suites exercise exactly the services a developer runs locally
+# and CI already knows how to provision. SeaweedFS is the intended deployment target (ADR 0004), and
+# proving the storage contract against a mock instead would have hidden the provider quirks this
+# suite exists to catch.
+if ! "${compose[@]}" up --detach --wait --wait-timeout 180 postgres object-storage >/dev/null 2>&1; then
+  echo "Disposable PostgreSQL and object storage did not become ready." >&2
   exit 1
 fi
 
@@ -77,8 +82,13 @@ if [[ "$COMPOSE_JOB_NETWORK_RUNNING_IN_CONTAINER" == "true" ]]; then
     echo "The migration test job could not join the isolated PostgreSQL network." >&2
     exit 1
   fi
+  if ! compose_job_network_connect object-storage "${compose[@]}"; then
+    echo "The migration test job could not join the isolated object-storage network." >&2
+    exit 1
+  fi
   database_host="postgres"
   database_port="5432"
+  storage_endpoint="http://object-storage:8333"
 else
   if ! postgres_binding="$("${compose[@]}" port postgres 5432 2>/dev/null)"; then
     echo "The disposable PostgreSQL loopback port could not be determined." >&2
@@ -94,11 +104,31 @@ else
     echo "The disposable PostgreSQL loopback port is invalid." >&2
     exit 1
   fi
+
+  if ! storage_binding="$("${compose[@]}" port object-storage 8333 2>/dev/null)"; then
+    echo "The disposable object-storage loopback port could not be determined." >&2
+    exit 1
+  fi
+  if [[ ! "$storage_binding" =~ ^127\.0\.0\.1:([0-9]+)$ ]]; then
+    echo "The disposable object-storage port is not bound safely to loopback." >&2
+    exit 1
+  fi
+  storage_port="${BASH_REMATCH[1]}"
+  if ((storage_port < 1 || storage_port > 65535)); then
+    echo "The disposable object-storage loopback port is invalid." >&2
+    exit 1
+  fi
+  storage_endpoint="http://127.0.0.1:$storage_port"
 fi
 
 # The TLS suite provisions its own disposable PostgreSQL rather than a Compose service, so it
 # cannot call `compose_job_network_connect`. It receives the same topology decision this script
 # already made, instead of detecting the topology a second time.
+# The storage credentials come from `.env.example`, the same file `--env-file` already hands the
+# Compose services, so the suite signs requests with exactly what the service was started with.
 EKKLESIA_TEST_JOB_CONTAINER="$(compose_job_network_job_container)" \
 EKKLESIA_MIGRATION_TEST_DATABASE_URL="postgresql://$POSTGRES_USER:$POSTGRES_PASSWORD@$database_host:$database_port/$POSTGRES_DB" \
+EKKLESIA_TEST_STORAGE_ENDPOINT="$storage_endpoint" \
+EKKLESIA_TEST_STORAGE_ACCESS_KEY="$(grep -E '^S3_ACCESS_KEY=' .env.example | cut -d= -f2-)" \
+EKKLESIA_TEST_STORAGE_SECRET_KEY="$(grep -E '^S3_SECRET_KEY=' .env.example | cut -d= -f2-)" \
   pnpm exec vitest run --config vitest.migrations.integration.config.ts