feat(shell): Settings hierarchy, Discover, and /settings/<module-id>

The Settings foundation (ADR 0061):

- URL model. /settings is a real landing page. The platform sections
  are /settings/general, /branding, /displays, and /system. Module
  lifecycle is Discover: /settings/discover/browse, /installed, and
  /updates. /settings/discover is respelled in place to Browse's one
  canonical address. A module's settings are /settings/<module-id>,
  never nested under Discover. Deeper Settings addresses are
  reserved. "Modules" stays the user-facing word: "Discover modules",
  "Installed modules", "Module updates".
- Collisions. Core's one reserved list gains the Settings section
  names (branding, discover, displays, general, system) as a second
  documented group, so no module id can shadow a section; `modules` is
  an ordinary id. apps/api tests hold it equal to the shell's sections.
- Navigation. One Settings item in the same sidebar expands in place
  into Platform and Modules (and Discover's three views) while in
  Settings, and the phone drawer has the same hierarchy. The rest of
  the navigation stays.
- Permissions. GET /api/v1/dashboard/settings evaluates, through
  Core's evaluator, which destinations the viewer may see:
  - Displays: core.devices.manage
  - Discover: core.modules.lifecycle.manage
  - a module's settings: core.modules.configuration.manage, for each
    module that declares configuration (ADR 0029)
  - General, Branding, System: the platform owner, until each has its
    own permission
  These are presentation hints; every data route keeps its own
  enforcement. With nothing visible, there is no Settings link.
- Pages are honest placeholders with Back to Settings. A disabled
  module's settings say it is turned off; a section or module the
  person cannot see says so without detail; an unknown name is not
  found; a failed load withholds the link and offers Retry.
- The deploy smoke opens Settings by deep link, refreshes a section,
  enters Discover, opens the module's settings, uses the phone
  drawer, and returns to the Dashboard.

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

apps/api/tests/dashboard-host-routes.test.ts

@@ -21,6 +21,8 @@ import {
   type ModuleDatabase,
   type ModuleLifecycleConfiguration,
   RESERVED_MODULE_IDS,
+  RESERVED_SETTINGS_NAMES,
+  RESERVED_TOP_LEVEL_NAMES,
 } from "@ekklesia/core/modules";
 import { describe, expect, it, vi } from "vitest";
 
@@ -40,7 +42,7 @@ import {
   DashboardHostConfigurationError,
   createDashboardHostRoutes,
 } from "../src/dashboard-host-routes.js";
-import { DASHBOARD_PLATFORM_PAGES } from "@ekklesia/shell/dashboard-routes";
+import { DASHBOARD_PLATFORM_PAGES, SETTINGS_SECTIONS } from "@ekklesia/shell/dashboard-routes";
 import {
   MODULE_DISPLAY_DESCRIPTOR_PREFIX,
   MODULE_DISPLAY_PAGE_PREFIX,
@@ -391,7 +393,7 @@ describe("the platform's reserved top-level names (ADR 0057)", () => {
     ]) {
       expect(isReservedModuleId(path.split("/")[1] ?? ""), path).toBe(true);
     }
-    expect([...RESERVED_MODULE_IDS].sort()).toEqual([
+    expect([...RESERVED_TOP_LEVEL_NAMES].sort()).toEqual([
       "account",
       "api",
       "assets",
@@ -402,9 +404,19 @@ describe("the platform's reserved top-level names (ADR 0057)", () => {
 
   it("include every Dashboard platform page the shell interprets", () => {
     for (const page of DASHBOARD_PLATFORM_PAGES) {
-      expect(RESERVED_MODULE_IDS, page).toContain(page);
+      expect(RESERVED_TOP_LEVEL_NAMES, page).toContain(page);
     }
   });
+
+  it("include exactly the Settings sections the shell interprets, so /settings/<module-id> never collides (ADR 0061)", () => {
+    expect([...SETTINGS_SECTIONS].sort()).toEqual([...RESERVED_SETTINGS_NAMES]);
+    for (const section of SETTINGS_SECTIONS) {
+      expect(isReservedModuleId(section), section).toBe(true);
+    }
+    expect(RESERVED_MODULE_IDS).toEqual(
+      [...RESERVED_TOP_LEVEL_NAMES, ...RESERVED_SETTINGS_NAMES].sort(),
+    );
+  });
 });
 
 describe("GET /assets/ekklesia-dashboard/app.js (the Dashboard script)", () => {