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]>

docs/development/security.md

@@ -544,6 +544,44 @@ is **where it can be invoked**, not a weaker policy:
 It deliberately does not solve creating *additional* users or owners. That is user administration,
 which does not exist yet.
 
+### A display device is a principal, not a person and not a shortcut
+
+An unattended screen has its own identity, paired by an administrator and revocable by one
+([ADR 0036](../architecture/decisions/0036-managed-device-identity-and-pairing.md)). What makes that
+safe is what it is *not* allowed to be:
+
+- **Not a user.** No device row exists in the identity tables and no device has an email or a
+  password. A device satisfies the `authenticated` baseline **never**, so every route that settles
+  for "somebody is signed in" stays closed to a television.
+- **Not a bypass.** Device authority is decided by the same `createAuthorizationEvaluator` as
+  everyone else's, with the same deny-by-default. There is no device branch that returns allowed
+  before consulting an explicit permission, and no device is ever a platform owner.
+- **Not broadly granted.** Approval grants exactly the one display permission the host derived from
+  the module's own validated display declaration. A browser cannot ask for a permission of its
+  choosing, and a device paired for one display has no authority over another.
+- **Not a Dashboard login.** `/api/v1/principal` reports a device as anonymous, and the shell tests
+  for `=== "authenticated"` rather than "not anonymous". A device cookie cannot open the Dashboard.
+- **Not the pairing code.** The six-digit code is displayed on a wall and is treated as public. It
+  identifies a request to an administrator; it never yields a credential. Collecting the credential
+  additionally requires the HttpOnly claim cookie only the requesting browser holds, so reading a
+  code off a screen is worth nothing.
+- **Not stored in a usable form.** The server keeps SHA-256 of the credential. The raw value exists
+  only in the `Set-Cookie` that issues it and in the device's own cookie jar; it is never logged, put
+  in a query string, returned in JSON, or written to `localStorage`. The cookie is `HttpOnly`, so the
+  module display code running in that very page cannot read it.
+- **Not revocable only at the browser.** Revocation is a server-side column checked on every
+  principal resolution. A revoked screen keeps its cookie and stops working; re-pairing creates a
+  **new** identity, so an old credential can never be reactivated.
+
+Approval, listing, and revocation require the restricted `core.devices.manage` permission and an
+exact trusted `Origin`, exactly like every other Core mutation. A device cannot approve a pairing —
+including its own.
+
+**Bounded, not instantaneous.** A revoked device fails its next request and its next realtime
+connection immediately, but an already-open SSE stream is not torn down at that moment: realtime's
+five-minute forced reconnect is the upper bound on how long a just-revoked screen can keep receiving
+a channel. That window is stated rather than described as instant.
+
 ### Rate limiting is per-process today
 
 Better Auth's authentication rate limiter is **in-memory and per API process**. That is acceptable