feat: let a display survive its network — as code, not as authorization

A display is the one surface expected to outlive its network: a television on
a wall in a building whose uplink is a consumer router, with nobody standing
in front of it. When that uplink drops and the screen reboots, the browser
shows its own error page — not the display shell, not an Ekklesia message,
nothing that recovers on its own, because there is no Ekklesia code left
running to recover.

Cache the shell and the declared code, in a service worker scoped to
`/display/`: the page, the host script, the module's display artifact, and
every contributed renderer that display actually mounted. All of them are code
whose bytes already confer no authority, and all of them are addressed by a
URL carrying an exact version.

Cache nothing else, ever. Not the descriptor, not `/api/v1/principal`, not a
module or platform API response, not the realtime stream, not a pairing
exchange, and not any cross-origin request — which is what a signed
object-delivery URL is. It is an allowlist rather than a deny list, so the
cost of forgetting a new endpoint is that code goes uncached rather than that
a permission decision gets stored.

The consequence is stated rather than papered over: a display cannot render
module content while offline. Mounting needs a descriptor, a descriptor is
authorization-bearing, and it is never cached — so a revoked device stays
revoked and cached code can never manufacture current authorization. What the
cache buys is that a kiosk rebooting mid-outage boots into Ekklesia's own
offline state and keeps retrying, that reconnecting mounts with nothing left
to download, and that a hiccup fetching 600 KB of artifact after the tiny
descriptor already resolved falls back to identical bytes instead of failing
the display.

Network-first everywhere, so a screen picks up new code the moment the server
returns and can never be trapped on an obsolete build — the failure mode a
cache-first worker produces on a screen nobody visits. Only a complete
same-origin 200 is stored. Cache names carry a policy version and superseded
generations are deleted; artifacts are pruned to the current version per
module, keeping every artifact belonging to that version because a display
artifact and its contributed renderers share one. The worker never caches
itself.

The page gets a small signal built from two sources, because either alone
lies: `navigator.onLine` is optimistic behind a captive portal, and only the
worker knows it actually served from cache. A display shows a quiet corner
indicator rather than blanking a lobby wall, and resolves its descriptor again
by itself when the network returns — nobody presses Retry on a lobby TV.

Every caching decision lives in a module that touches no global, so the
behaviour is exercised directly rather than through a worker a test runner
cannot host. Registration is an enhancement: no service workers, plain HTTP,
or a refusing policy all leave a display that works exactly as before.

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

docs/module-development/README.md

@@ -746,7 +746,7 @@ eligible, running, and declares `entrypoints.display`, Ekklesia registers exactl
 
 The page and descriptor both require the manifest's display permission through the ordinary Core
 authorization evaluator and an authenticated cookie session. A `public` display permission is
-rejected in manifest version 6; there is no anonymous exception or device token. Artifact bytes are
+rejected; there is no anonymous exception or device token. Artifact bytes are
 anonymous for the same reason as primary UI bytes: code alone carries no data authority. Unknown,
 primary-only, disabled, and dependency-blocked modules have no display routes and return the normal
 sanitized `404`. Enabling, disabling, installing, or changing the manifest takes effect on restart,
@@ -764,8 +764,31 @@ artifact remains compatible with a future standalone host.
 The display host fills the viewport but deliberately does **not** invoke the browser Fullscreen API.
 It shows fixed loading/failure states and offers manual retry; your module owns only the rendered
 feature experience and cleanup inside its container. There is one display per module. Display
-inventory/management, named variants, targeting, public/device identity, a standalone host, shared
-CSS, Announcements migration, and Companion integration are deferred.
+inventory/management, named variants, targeting, public/device identity, a standalone host,
+Announcements migration, and Companion integration are deferred.
+
+### Your display survives a network outage — as code, not as content
+
+A display page is controlled by a service worker that caches **the shell and the declared code**: the
+page, the host script, your display artifact, and every contributed renderer that display actually
+mounted ([ADR 0043](../architecture/decisions/0043-display-offline-code-fallback.md)). Caching is
+network-first, so a screen picks up a new build the moment the server returns and can never be
+trapped on an obsolete one.
+
+What that means for you, concretely:
+
+- **Your artifact will be served from cache when a fetch fails.** The bytes are identical and the
+  loader still verifies the artifact's declared id and version, so a fallback can never mount
+  something the descriptor did not name.
+- **Your display cannot render while the network is down.** Mounting requires the descriptor, the
+  descriptor is authorization-bearing, and it is never cached — so a device whose access was revoked
+  stays revoked, and cached code can never manufacture authorization it no longer has. The screen
+  shows Ekklesia's own quiet offline indicator and resolves again by itself when connectivity
+  returns.
+- **Nothing of yours is cached but code.** Your module's API responses, your realtime stream, and
+  every signed object-delivery URL are deliberately never stored. If you want a screen to keep
+  showing content through an outage, persisting that content is *your module's* job — this is the
+  foundation it would build on, not a substitute for it.
 
 ### What a module UI will never own