Manage paired displays: themed select, reassignment, live list, no revoked clutter

Real-device review of the platform display flow found four defects in
display management:

- Shared SelectMenu in @ekklesia/ui (additive): an Ekklesia-drawn
  single choice following the WAI-ARIA select-only combobox pattern,
  replacing the native select for "Show on this screen". It has a
  themed list, a chevron inside the control, keyboard support (arrows,
  Home/End, type-ahead, Enter/Space/Tab, and Escape that closes only
  the list), pointer and touch support, and focus that stays on the
  control. It is an ek-control, so it keeps the 16px phone size.
- Newly paired displays appear without a reload. Approval doesn't
  create the display; the screen does when it claims its credential a
  few seconds later. The page now shows a "Waiting for the screen to
  connect" placeholder and refetches every second until the new display
  appears (for up to a minute), and refreshes the list every 30
  seconds.
- What a display shows can change after pairing. In the single-target
  Stage 1 model, a display's current target is its one active display
  permission, so no migration is needed.
  PUT /api/v1/devices/:id/display, with core.devices.manage, a trusted
  origin and a bounded body, revokes its other active permission rows
  (kept as history) and grants the chosen module's declared display
  permission, in one transaction on the same device. The screen notices
  within about 30 seconds: a paired device on a module page that is no
  longer set to show it goes to /display/setup instead of re-pairing,
  and /display/setup opens the new target.
- Revoked displays leave the normal list at once. Their rows stay in
  the database as history.

Each display card now shows its name, Online/Offline/Not connected yet,
"Showing: ...", last seen and paired dates, and Change and Revoke.

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

docs/development/api.md

@@ -1007,6 +1007,7 @@ sets, never the code):
 | `POST /api/v1/device-pairing/approvals` | Body `{code, deviceName, moduleId?}`. The administrator names the screen; the screen never names itself. `moduleId`, for a platform display, is the running display module it shows; its declared display permission is granted. A module display's own request cannot be given a different module. |
 | `GET /api/v1/devices` | Paired devices: name, permissions, created, last seen, revoked. Never a credential. |
 | `GET /api/v1/devices/display-modules` | `{modules: [{moduleId, name, permissionId}]}`: the running modules a display can be set to show. |
+| `PUT /api/v1/devices/:deviceId/display` | Body `{moduleId}` (a running display module, or `null`). Sets what the display shows: its other active permissions are revoked (kept as history) and that module's declared display permission is granted. Same identity, name, and credential. `404` for a revoked or unknown display. |
 | `POST /api/v1/devices/:deviceId/revoke` | `204`. Server-side revocation, checked on every principal resolution. |
 
 The pairing code travels in request **bodies**, never a path or query, so it does not land in access

docs/development/testing.md

@@ -497,6 +497,19 @@ proven here:
 - `apps/api/tests/module-display-routes.test.ts` serves `/display/setup` and the display host with
   zero display modules, and only with device support.
 - `core/tests/device-pairing-schema.test.ts` pins migration `0009` to its three additive statements.
+- `apps/api/tests/device-pairing.integration.ts` also changes a display from nothing to a module,
+  between two modules, and back. It checks that the display keeps one identity, name, and credential,
+  that the module descriptors follow, that the history rows are kept, and that revoked displays and
+  bad requests are refused.
+- `packages/ui/tests/select-menu.test.tsx` covers `SelectMenu`:
+  - its combobox and listbox semantics, and no native select;
+  - the keyboard: arrows, Home, End, type-ahead, Enter, Space, and Tab;
+  - Escape closing it without closing a surrounding dialog;
+  - pointer and outside presses, the disabled state, and token-only styling.
+- `surfaces/shell/tests/display-app.test.tsx` covers a running module display:
+  - moved to another module, or refused while still paired, it goes to `/display/setup`;
+  - an unpaired screen still shows a code;
+  - a person previewing the page is never moved.
 - `surfaces/shell/tests/display-setup-app.test.tsx` covers the setup page:
   - it pairs with no module and waits, named;
   - it opens the module it is set to show;
@@ -504,6 +517,10 @@ proven here:
   - it returns to a code when revoked;
   - it never pairs on a server failure.
 - `surfaces/shell/tests/displays-settings.test.tsx` covers:
+  - active displays only, with status and what each shows;
+  - a newly paired display appearing without a reload, and never twice;
+  - **Change** moving a display between nothing and modules as the same display;
+  - a revoked display leaving the list at once;
   - the platform setup address, and **Copy setup link**;
   - **Add display** with zero display modules;
   - the **Show on this screen** choice;