Fix the Stage 1 Dashboard UX defects found in assembled review

The assembled Stage 1 Dashboard was reviewed by hand on a desktop, with
the sidebar collapsed, and on an iPhone. This fixes what that review
found, and records the decisions in ADR 0064:

- Discover is its own page at /settings/discover, with Installed and
  Updates beneath it as children. There is no Browse item any more.
  /settings/discover/browse is still read, as an alias, and is respelled
  in place. Parents and children now read as a hierarchy: a guide line,
  text-only children, a disclosure chevron, and parent and current
  states that look different.
- The sidebar is navigation only. Display pairing moves from the sidebar
  and drawer to Settings -> Displays: the paired displays, a deliberate
  Add display dialog, and revocation. Nothing takes focus on arrival;
  the code field is focused only once Add display is chosen.
- Collapsed icons are centred. Nav-link layout moves from inline styles
  to the shell stylesheet, and every collapsed item is one square
  centred on the rail.
- /settings is an overview of the installation: displays paired,
  modules installed and running, and a line for each other area. It
  reads only existing endpoints.
- Phones get a sticky, safe-area-aware header holding the menu trigger
  and the page name. New pages start at the top, and focus no longer
  scrolls content under the header.
- @ekklesia/ui draws checkbox and radio indicators from tokens rather
  than accent-color, so the selected state is the strong accent in
  Light and Dark alike.

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

CLAUDE.md

@@ -54,11 +54,11 @@ Rules from those documents that every change here must respect:
   (`@ekklesia/design-tokens`, ADR 0039) — never a hard-coded colour.
 - **No browser-native dialogs.** `window.alert`, `window.confirm`, and `window.prompt` are prohibited
   in product UI. Destructive actions use in-product confirmation proportional to their impact.
-- **Displays are transitional.** Displays are platform-owned. Today's device pairing (the Dashboard
-  sidebar's *Display devices* panel) and Signage's own display roster are a transitional
-  implementation that Stage 1 migrates to **Settings → Displays**. Fix defects in them, but do not
-  build the Stage 1 Settings, global Displays, theme editor, module installer, or responsive shell
-  redesign early, and keep existing paired displays working across any change.
+- **Displays are platform-owned.** Display pairing lives in **Settings → Displays** (ADR 0064); the
+  sidebar is navigation only. Signage's own display roster is still a transitional implementation
+  that Stage 1 replaces with the platform's displays. Keep existing paired displays working across
+  any change, and do not build a module installer, theme editor, or display features beyond what a
+  task asks for early.
 
 ## ADRs are authoritative