feat: add Dashboard navigation as presentation configuration

Phase 6D pass 1. The shell's navigation was a flat list of module ids, which
is not a usable experience — and the obvious fix carries an obvious trap.
Letting a module declare its folder, or modelling "Media" as something
Livestream and Video belong to, turns a rendering preference into
architecture: a folder becomes an owner, membership starts to look like a
dependency, and the flat module graph acquires a hierarchy nobody decided on.

So the rule comes first: a Dashboard group is a label on a rendering bucket.
No manifest, no version, no artifact, no API, no lifecycle; nothing depends on
it. Livestream depends on Video because it calls Video's functionality, and
that orders startup. Livestream is shown under Media, and that orders nothing.
No parent module, child module, owning module, or group-derived dependency
appears anywhere in the contracts.

No manifest change and no version 5. `manifest.name` has been required since
version 1 and already is the module's product identity, so the shell renders
"Livestream" instead of `livestream` with nothing added. `suggestedGroup` is
deliberately deferred rather than shipped: it would force a hard
manifest-version cutover for a hint, and its only correct semantics needs
initialization logic that risks a suggestion overwriting an administrator's
decision. Defaulting and ownership are different things.

Two Core tables (migration 0003) hold groups and placements — server-side,
because a church configures its Dashboard rather than one browser;
platform-global, because no organization model exists to scope them to.
`group_id` is `on delete set null`, so deleting a group ungroups its modules
and a dangling reference is impossible. `module_id` carries no foreign key,
because modules are packages rather than rows, so a placement for an
uninstalled module is retained and restores its position on reinstall.

`resolveDashboardNavigation` is a pure function of configuration plus the
mountable set: an unplaced module is ungrouped and visible with no
initialization write, an absent module renders nothing, empty groups are kept,
and ordering is total with the module id as final tie-break.

`GET /api/v1/dashboard/navigation` returns the resolved view, layered on top of
the host-neutral module UI inventory rather than merged into it — each generic
descriptor is embedded untouched, so a standalone host never inherits Dashboard
semantics. Reading needs the permission the inventory already needs; organizing
needs the new platform permission `core.dashboard.navigation.manage` through a
narrow, idempotent, closed-validation mutation contract. No editor UI.

The flatness rule is executable: a test discovers real fixtures with a genuine
dependency, arranges them four ways including both in one folder and the
dependency inverted in presentation, and asserts discovery order, dependency
declarations, and the module set stay byte-identical. The end-to-end test
organizes a real installation through the real API, mounts a module from inside
a group, moves it, and asserts the navigation entry is byte-identical across the
move and still mounts the same artifact.

The shell's client for the generic inventory became dead code and was removed
rather than kept speculatively; the endpoint itself is unchanged.

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

docs/module-development/README.md

@@ -155,6 +155,27 @@ module's own HTTP routes, and creating relationship-derived grants automatically
 own business logic, are both still later work; this only makes a declared permission *usable*
 through Core's existing, generic surface.
 
+### Your module's display name
+
+`name` — required by the manifest since version 1, trimmed, 1–120 characters — is what a person sees
+in Ekklesia's Dashboard navigation. It is your module's **product identity**: what the product is
+called, which you own. Set it to something a church staff member would recognize ("Livestream"), not
+your package name or module id.
+
+**You do not declare where your module appears.** Dashboard groups — "Media", "Planning", "Sunday
+Production" — are presentation configuration an administrator owns, stored by the platform and
+changed at any time without touching your module
+([ADR 0027](../architecture/decisions/0027-dashboard-navigation-and-flat-modules.md)). There is no
+manifest field for a folder, a group, an order, an icon, or a category, and adding one would make a
+rendering preference into module structure.
+
+That separation also means grouping never affects you. Two modules sharing a folder have no
+relationship: no dependency, no ordering, no shared anything. If your module genuinely needs another
+module's functionality, declare it in `dependencies.modules` — that is the only kind of module
+relationship the platform has, and it is what orders discovery and startup. An administrator moving
+your module into a different folder changes nothing about your artifact, your API root, your
+permissions, your dependencies, or when you start.
+
 Every entrypoint except `migrations` must be a compiled ESM `.js` or `.mjs` file — `server`,
 `schema`, `jobs`, and `ui` alike. `migrations` is the one directory entrypoint. All entrypoints begin
 with `./`, remain inside the package, and exist. Production never imports source TypeScript directly.
@@ -499,9 +520,10 @@ Three things follow for you:
   API root; a path that escapes it (`"../other-module/records"`, an absolute URL) is refused before
   it becomes a request. Keep asking for relative paths and your artifact stays hostable elsewhere.
 
-> **This is not the Dashboard.** The shell is a module list and a mount target. There is no
-> navigation, grouping, icons, ordering, theme, or design system yet, and the selector shows your
-> module's id — the inventory deliberately carries no display metadata until that design exists.
+> **This is not the finished Dashboard.** The shell renders one level of grouping and mounts the
+> selected module. Your module appears under whatever group an administrator placed it in — by its
+> `name`, never its id — and under "Other" until someone arranges it. There is no navigation editor,
+> no nested folders, no icons, no theme, and no Dashboard Home yet.
 
 ### What a module UI will never own