feat: give display devices their own paired identity

ADR 0033 gave Ekklesia a display host and ADR 0034 gave it a login page.
Together, the only way to light a television in a foyer was to sign a
human being into it and leave that session running on a screen anyone can
walk up to: a person's credentials on a wall, a person's session as the
thing signage depends on, and the display going dark when they are
revoked or their session simply expires.

A screen is not a person. Ekklesia now recognizes three principal classes
— anonymous, authenticated human, and managed device — and a device is a
first-class principal with its own credential and its own explicit
permissions. It has no email, no password, and no row in the identity
tables, and it satisfies the `authenticated` baseline never, so every
route that settles for "somebody is signed in" stays closed to it.

Device permissions live in their own table because
ekklesia_core_grant.user_id is a non-null foreign key into the user table
and making it polymorphic would rewrite the platform's central
authorization record to serve one narrow case. That is a schema decision,
not a second decision point: the evaluator gained one branch, so a device
is allowed or denied by the same function, with the same deny-by-default,
as anyone else — with no owner path it could reach and no baseline that
stands in for a grant.

The six-digit code is not the credential. It is printed across a screen in
a public hallway, so it is treated as public: it identifies a request to
an administrator and is worth nothing alone. Collecting the credential
also requires a 256-bit claim secret held only in the requesting browser's
HttpOnly cookie, and approving requires the restricted core.devices.manage
permission. Without that split, reading a code off a wall would hand over
the screen's identity.

The permission a pairing asks for is read from the module's validated
display declaration, never from the request, so a browser cannot ask to be
granted core.devices.manage or another module's permission. Approval
grants exactly that one permission.

Credentials are stored only as SHA-256; the raw value exists in the
Set-Cookie that issues it and the device's own cookie jar, and is never
logged, returned in JSON, or placed in a URL. The cookie is HttpOnly, so
the module display code running in that same page cannot read it.
Revocation is a server-side column checked on every principal resolution,
and re-pairing mints a new identity so an old credential can never come
back. State transitions are conditional updates, so one code cannot be
approved twice or claimed into two credentials under a race.

/api/v1/principal still reports a device as anonymous: it is what the
Dashboard uses to decide whether a person is signed in. Displays read
their viewer from the descriptor instead, which already performed the
authorization — so displays are descriptor-first while the Dashboard stays
principal-first, and neither infers an identity by elimination.

Proven end to end against real PostgreSQL and real HTTP: an unpaired
screen shows a code, an owner approves it, the device opens the display
descriptor and a realtime stream, and revocation closes both while the
device still holds its cookie. An already-open SSE stream is bounded by
realtime's existing five-minute reconnect rather than closed instantly,
and that bound is documented rather than called immediate.

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

README.md

@@ -651,13 +651,46 @@ adds an optional, independently declared display role:
 }
 ```
 
-The permission must be declared by that module and have an `authenticated` or `restricted` baseline;
-public/device identity remains deferred. Primary UI and display UI are independently optional, must
+The permission must be declared by that module and have an `authenticated` or `restricted` baseline. Primary UI and display UI are independently optional, must
 use paths distinct from every other entrypoint, and use the same
 `defineModuleUi({ id, version, mount })` ABI and five-member `ModuleUiHostContext` with **no mode
 flag**. The canonical builder reads fixed sources (`src/ui/index.tsx` and
 `src/display/index.tsx`) and atomically emits every declared role.
 
+Phase 7B pass 2 gives those screens an identity of their own
+([ADR 0036](docs/architecture/decisions/0036-managed-device-identity-and-pairing.md)), so a
+television no longer needs a person signed into it. Ekklesia now recognizes **three** principal
+classes — anonymous, authenticated human, and managed device:
+
+```text
+screen opens /display/announcements → no identity → shows a 6-digit code
+administrator types the code in the Dashboard, names the screen, approves
+screen collects an HttpOnly credential → display and realtime work
+administrator revokes → the screen loses access and shows a code again
+```
+
+**A device is not a user.** It has no email, no password, and no row in the identity tables, and it
+satisfies the `authenticated` baseline *never* — so every route that settles for "somebody is signed
+in" stays closed to a screen on a wall. Device authority runs through the same authorization
+evaluator as everyone else's, and approval grants exactly the one display permission the host derived
+from the module's own declaration. `/api/v1/principal` reports a device as anonymous on purpose: a
+device cookie cannot open the Dashboard.
+
+**The code is not the credential.** Six digits are printed across a television in a public hallway,
+so they are treated as public: they identify a request to an administrator and yield nothing on their
+own. Collecting the credential also requires an HttpOnly claim cookie only the requesting browser
+holds, and approving requires the restricted `core.devices.manage` permission. The credential itself
+is stored only as a SHA-256 digest, never logged, never in a URL, and never readable by the module
+display code running in that same page.
+
+Revocation is a server-side fact checked on every request, not a plea that a remote browser forget
+something; re-pairing creates a **new** identity so an old credential can never come back. A revoked
+screen fails its next request immediately, though an already-open realtime stream is bounded by the
+existing five-minute forced reconnect rather than closed instantly. **QR scanning, per-device content
+targeting, device groups, and mobile dashboards are deliberately deferred** — a future QR simply
+encodes the same short code, and the pairing API is not desktop-specific. Ekklesia Lite has no device
+identity at all.
+
 Ekklesia publishes the display bundle at
 `GET /api/v1/module-ui/<module-id>/<version>/display`, serves a stable permission-gated page at
 `/display/<module-id>`, and exposes that page's permission-gated descriptor at