feat: deliver module objects directly to browsers through opaque read URLs

ADR 0030 left exactly one way to get an image to a browser: read the
object into the module's process and write it back out of a module HTTP
route. Every byte of every asset travelled storage -> Ekklesia -> browser.
For the slideshow this platform exists to replace that means Ekklesia in
the path of every image on every display, permanently, for bytes that
never change — and it would make Ekklesia responsible for re-implementing
byte ranges, without which video seeking cannot work at all.

A module can now ask a logical bucket for a temporary browser URL:

    const { url, expiresAt } = await assets.createReadUrl("slides/welcome.png");

The contract names intent, not mechanism. There is no signing, expiry
format, endpoint, or bucket in it — a host with no S3 anywhere could
satisfy the same method, which is what keeps a future single-module
standalone host able to implement it. The URL is opaque to module code and
a bearer capability to whoever holds it, so a module authorizes the
request in its own route before asking: storage bounds reach, never
identity. Lifetimes run one minute to six hours, fifteen by default, and
out-of-range values are refused rather than clamped, so "expires forever"
is unreachable. Logical keys stay canonical state; URLs are generated on
demand and never persisted or logged.

The provider endpoint and the browser delivery origin are separated
because measurement showed they cannot be collapsed: an S3-compatible
signature covers the request Host, so a URL signed for one origin and
rewritten to another is rejected. The browser-facing origin is therefore a
signing input (S3_DELIVERY_ENDPOINT), defaulting to S3_ENDPOINT — so the
standard deployment configures nothing and delivery just works. The scheme
is not signed, so a reverse proxy may terminate TLS provided it passes the
original Host through; that is pinned by a test rather than described and
hoped for.

Read URLs are stable within a window of one third of their lifetime.
Signing is a pure function of the clock, so naive re-signing yields a new
URL per second — a guaranteed browser cache miss, and the reference client
keys its <img> by URL, so an unchanged image would be torn down and
re-downloaded continuously. Quantizing the signing timestamp makes
repeated calls byte-identical while leaving at least two-thirds of the
lifetime; Cache-Control is set at signing time to the guaranteed
remainder, because the pinned SeaweedFS image sends none of its own.

Verified against live SeaweedFS: byte ranges answered directly with 206
and a correct Content-Range, so no range proxy is needed in Core; signing
is local (200 URLs in 66ms), so no batch API is needed; unsigned requests
for the same object are refused, so delivery never depends on a public
bucket; tampered signatures, swapped keys, and swapped buckets all
rejected. Signed write and delete URLs are deliberately not built.

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

README.md

@@ -13,7 +13,8 @@ against an independent security audit) is complete: all five passes have landed
 independent whole-repository re-audit has closed, under the current trusted-contributor,
 not-yet-deployed threat model — and Phase 6 is unblocked and underway.** Phase 6 has since
 completed through 6D, and **Phase 7A passes 1 (the minimal operational module lifecycle), 2 (the module configuration and
-secrets contract), and 3 (host-provided module object storage) have landed.** The operational
+secrets contract), 3 (host-provided module object storage), and 4 (direct browser object delivery)
+have landed.** The operational
 requirements that remain are prerequisites for two specific *future* activities — executing
 untrusted CI contributions, and a public production launch — and neither gates Phase 6; see the
 pass 5 closure below and
@@ -561,12 +562,42 @@ modules, module UI, diagnostics, or any API response — errors are translated t
 carries no endpoint, bucket, request id, or XML. This also retires the transitional `bucket`
 *configuration* key ADR 0029 flagged: the manifest declaration is the requirement.
 
-Browsers reach objects through a module's own routes (`browser → module API → scoped storage`), so no
-S3 knowledge or credential goes near the browser. **Signed URLs, public object delivery, range
-requests, and multipart upload are deliberately deferred**, and the provider is not yet
-"production-ready" by ADR 0004's own bar. See
+Multipart upload is deliberately deferred, and the provider is not yet "production-ready" by
+ADR 0004's own bar. See
 [ADR 0030](docs/architecture/decisions/0030-host-provided-module-object-storage.md).
 
+Phase 7A pass 4 takes Ekklesia **out of the data path** for assets a browser is going to fetch
+anyway. A module asks its logical bucket for a temporary browser URL and returns it; the browser
+fetches the object from the storage service directly:
+
+```ts
+const { url, expiresAt } = await context.storage
+  .bucket("announcement-assets")
+  .createReadUrl("slides/welcome.png");
+```
+
+The contract still names no mechanism — no signing, no endpoint, no expiry format — so a host with no
+S3 in it could satisfy the same method. The URL is **opaque** to module code and a **bearer
+capability** to whoever holds it, so a module authorizes the request in its own route before asking
+for one: storage bounds *reach*, never *identity*. Lifetimes run from one minute to six hours,
+fifteen minutes by default, and out-of-range requests are refused rather than clamped. Modules
+persist logical keys and generate URLs on demand; a stored URL would be a stored credential.
+
+This is what makes media practical. A `Range` request against a delivery URL is answered by the
+storage service directly — verified `206` with a correct `Content-Range` — so byte-range seeking needs
+no proxy in Core. Signing is local, so a slideshow builds one URL per slide with no round trips, and
+repeated calls inside a window return a byte-identical URL so browser caches and URL-keyed DOM
+elements hold.
+
+Because an S3-compatible signature covers the request's `Host`, a URL cannot be signed for one origin
+and rewritten to another. The origin a browser uses is therefore a signing input
+(`S3_DELIVERY_ENDPOINT`), defaulting to `S3_ENDPOINT` — so the standard deployment configures nothing
+and delivery simply works. A reverse proxy in front of storage must pass the original `Host` through
+unchanged; it may terminate TLS, because the scheme is not signed. Buckets stay private: an unsigned
+request for the same object is refused, and a test asserts it. **Signed write and delete URLs, and a
+realtime refresh transport, are deliberately deferred.** See
+[ADR 0031](docs/architecture/decisions/0031-direct-object-delivery.md).
+
 **Still not the finished Dashboard.** There is no navigation editor or drag and drop, no nested
 folders, no icons or colors, no Dashboard Home or widgets, no design system, no client-side routing,
 and no module-management, settings, or storage UI — module enablement and configuration are an API and