feat(api): serve the built Dashboard from the API origin

Serve surfaces/shell's built Dashboard from apps/api on the same origin
as /api (ADR 0044), exactly as the display host is served: a closed set
of files read once at startup, never a static directory, never a path
built from request input.

- The shell exports @ekklesia/shell/dashboard-assets (the exact built
  index.html and script URLs), emits the script at
  assets/ekklesia-dashboard/app.js, and index.html names that absolute
  path so dev and production serve the same URLs.
- GET / and GET /assets/ekklesia-dashboard/app.js answer from a frozen
  snapshot: no-cache with a strong ETag and 304 on match. Source maps
  are never served; every other path is the ordinary sanitized 404.
- The page sets nosniff, X-Frame-Options: DENY, Content-Security-Policy:
  frame-ancestors 'none' (that directive only), and Referrer-Policy:
  no-referrer, on 200 and 304 alike.
- A missing or empty shell build fails startup with a fixed
  DashboardHostAssetError before any module code is imported.
- The If-None-Match comparison moves to conditional-request.ts, shared
  with the display host routes.
- The emailed-link token stripping moves from browser/main.tsx into
  consumeAuthLanding (location and history injected) so it is tested;
  behavior is unchanged.

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

surfaces/shell/scripts/build-browser.mjs

@@ -42,7 +42,9 @@ const buildOptions = {
     "process.env.NODE_ENV": JSON.stringify(serve ? "development" : "production"),
   },
   entryPoints: {
-    app: path.join(packageDirectory, "src", "browser", "main.tsx"),
+    // Emitted under the exact path `apps/api` serves it from (ADR 0044), so the development server's
+    // `servedir` and production answer the same absolute URL `index.html` names.
+    "assets/ekklesia-dashboard/app": path.join(packageDirectory, "src", "browser", "main.tsx"),
     "display/app": path.join(packageDirectory, "src", "display", "main.tsx"),
     // The display service worker (ADR 0043). A separate entry because a worker is a separate
     // realm with its own globals; bundling it into the page would make it unregisterable and its