feat: add browser auth shell

README.md

@@ -11,13 +11,15 @@ Phase 4C (Core authorization), Phase 5A (module authorization integration), Phas
 transport), and Phase 5C (module database access) have landed. **Phase 5D (security hardening
 against an independent security audit) is complete: all five passes have landed and the final
 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
+not-yet-deployed threat model.** Phase 6 completed through 6D, and **Phase 7A passes 1 (the minimal
+operational module lifecycle), 2 (the
 module configuration and secrets contract), 3 (host-provided module object storage), 4 (direct
 browser object delivery), 5 (native module realtime transport), and 6 (the authenticated display/
-kiosk host) have landed.** The operational
+kiosk host) have landed. Phase 7B pass 1 adds the Dashboard's host-owned browser sign-in, sign-out,
+session-expiry handling, and authenticated-shell transition.** 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
+untrusted CI contributions, and a public production launch — and neither gates ongoing product
+development; see the
 pass 5 closure below and
 [Security model and deployment trust boundaries](docs/development/security.md). The repository includes
 public module contracts, independently versioned capabilities, static module manifests,
@@ -50,10 +52,11 @@ order never grants elevation — but is now **disabled by default, and cannot be
 production at all** until durable abuse controls exist (Phase 5D pass 1, below). See
 [API](docs/development/api.md) and
 [ADR 0011](docs/architecture/decisions/0011-identity-http-transport-and-public-enrollment.md).
-**No email verification, password recovery, or Dashboard exists yet** — that, along with
-production approval-provider composition, jobs, physical storage provisioning, surfaces, and
-feature modules, remains later vertical slices. Public registration is not yet ready for a real
-public launch.
+Email verification, password recovery, invitation/operator enrollment, and a supported production
+first-user creation path still do not exist. Public registration remains disabled by default and
+prohibited in production. The Dashboard now has a minimal authenticated shell and login/logout flow,
+but not a finished product UI or a production asset-hosting deployment; jobs, production
+approval-provider composition, feature modules, and the public Website remain later slices.
 
 Phase 4C adds Core's authorization foundation on top of identity: a schema, evaluator, and store
 for platform owners, explicit grants, and relationship-derived grants; a smallest-possible
@@ -235,15 +238,15 @@ never a dependency. The long-term goal is one module implementation hosted by Ek
 by a standalone application — never two codebases for one domain. See
 [ADR 0021](docs/architecture/decisions/0021-modules-as-hostable-products.md).
 
-**What that pass shipped is the static contract only.** `manifestVersion: 4` adds one
-optional field, `entrypoints.ui`, a package-relative path to a compiled ESM artifact validated
+**What that pass shipped at its checkpoint was the static contract only.** `manifestVersion: 4`
+added one optional field, `entrypoints.ui`, a package-relative path to a compiled ESM artifact validated
 during discovery exactly like `server` and `schema` — inside the package, real file, no source
-TypeScript. Discovery stays inert: **nothing imports, mounts, or renders that entrypoint**, exactly
-like the long-declared `entrypoints.jobs`. Upgrading a backend-only version 3 manifest is a
-one-character edit; version 3 is rejected outright rather than reinterpreted, as version 2 was
-before it. **The Dashboard shell, a UI runtime or renderer, navigation
-registration, Dashboard grouping, a standalone host, a module installer or marketplace, hot-loading,
-and every feature module do not exist.** Restart-based discovery, explicit operator-invoked
+TypeScript. Discovery stayed inert: **nothing imported, mounted, or rendered that entrypoint**,
+exactly like the long-declared `entrypoints.jobs`. Upgrading a backend-only version 3 manifest was a
+one-character edit; version 3 was rejected outright rather than reinterpreted, as version 2 was
+before it. The Dashboard shell, runtime mounting, and navigation named as absent at that checkpoint
+landed in subsequent Phase 6 passes. A standalone host, module installer or marketplace, hot-loading,
+and every real feature module still do not exist. Restart-based discovery, explicit operator-invoked
 migrations, and the trusted compiled-module model are unchanged.
 
 Phase 6B pass 1 answers the question Phase 6A deliberately left open: **what a module UI actually is,
@@ -666,11 +669,29 @@ flow through the unchanged host context. Display inventory/management, variants
 public/device identity, browser Fullscreen API behavior, a standalone host, a shared CSS system, the
 Announcements migration, and Companion integration remain deferred.
 
+Phase 7B pass 1 adds **host-owned browser authentication to the Dashboard shell**
+([ADR 0034](docs/architecture/decisions/0034-host-owned-browser-authentication.md)). Anonymous
+bootstrap renders an accessible email/password form; successful submission uses the existing
+`POST /api/auth/sign-in/email` endpoint, whose successful browser-visible body is reduced to fixed
+`{"ok":true}` while the HttpOnly cookie remains authoritative. The shell resolves
+`GET /api/v1/principal` again before protected navigation and module UI, and sign-out uses the
+existing `POST /api/auth/sign-out` before the same principal re-resolution. No token is stored or
+passed to a module, no arbitrary callback/return URL exists, and leaving authenticated state
+unmounts the active module through the generic loader's normal cleanup.
+
+The flow intentionally offers neither signup nor password recovery: production signup remains
+prohibited, no email sender exists, and the repository still lacks a supported way to create the
+initial production identity required by platform-owner bootstrap. Authentication throttling is
+enabled but in-memory and per API process. Host-only cookies, exact trusted origins, and Better
+Auth's origin/CSRF checks remain unchanged; production Dashboard DNS/TLS/proxy/CSP and built-asset
+hosting are deployment work, not guarantees added by this pass. Display device identity and the
+public Website remain separate future designs.
+
 **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
-a CLI, not a screen, and object storage is deployment configuration. Sign-in UI, a production CSP
-and deployment for the built shells, general sidecar asset publication, React runtime sharing, the
+a CLI, not a screen, and object storage is deployment configuration. A production CSP and
+deployment for the built shells, general sidecar asset publication, React runtime sharing, the
 standalone host, and every real feature module also do not exist.
 
 **Security model.** Installed modules are trusted compiled backend code that runs arbitrary