[UX] Module Hub und skalierbare Navigation für viele aktivierte Module einführen

[p3t3r67x0]

Teil von #108 und #91. Ergänzt #136 um die konkrete UX für viele aktivierte Module.

Problem

Das Frontend Module SDK kann Seiten und Navigation als Modulbeiträge liefern. Bei wachsender Zahl aktivierter Module darf daraus jedoch keine flache, unübersichtliche Hauptnavigation entstehen. Nutzer:innen müssen Module und deren Seiten schnell finden und gleichzeitig erkennen können, welche Funktionen zu welchem Modul gehören.

Ziel

Eine skalierbare, fachlich verständliche Module-Navigation einführen:

Host-Navigation
├─ Karte
├─ Daten
├─ Module
└─ Dokumentation

Module
├─ Suche
├─ Kategorien
├─ aktivierte Module
└─ Modul → bereitgestellte Seiten

Der Host rendert ausschließlich deklarative Modulmetadaten und Navigation Contributions. Keine hardcodierten Modulnamen oder Fachrouten im AppShell.

UX-Anforderungen

• eigener primärer Einstieg Module in der Host-Navigation;
• Module-Menü/Popover für schnellen Zugriff auf aktivierte Module;
• vollständige Module-Übersichtsseite für viele Module;
• Suche nach Modulname, Beschreibung und ggf. Seitentitel;
• Gruppierung nach fachlichen Kategorien wie Daten & Analyse, GIS & Karte, Beteiligung, ohne Kategorien im Host an konkrete Module zu koppeln;
• Modulkarte mit Name, Icon, Beschreibung, Version, Publisher/Trust-Hinweis soweit verfügbar;
• Seiten eines Moduls klar unter diesem Modul gruppiert;
• aktive Module zuerst, verfügbare/nicht aktivierte Module nur wenn entsprechende Registry-/Operator-UX bewusst unterstützt wird;
• mobile, Tablet und Desktop nutzbar;
• Tastaturbedienung, Fokusführung und Screenreader-Semantik;
• keine Navigationseinträge für disabled Module.

Technischer Contract

Prüfe/erweitere das bestehende Frontend Module SDK um deklarative Presentation-/Navigation-Metadaten, z. B. sinngemäß:

interface ModulePresentation {
  moduleId: string
  name: string
  description?: string
  icon?: string
  category?: string
  publisher?: string
}

interface NavigationContribution {
  moduleId: string
  sections: Array<{
    id: string
    label: string
    pages: Array<{
      label: string
      route: string
      description?: string
      icon?: string
      order?: number
    }>
  }>
}

Bestehende Contracts wiederverwenden und nur ergänzen, wenn nötig. Kein paralleles zweites Navigationsmodell.

Skalierung

Mindestens mit Fixtures für:

• 2 Module;
• 10 Module;
• 25 Module;
• Module mit 1 bzw. vielen Seiten;
• mehrere Module derselben Kategorie.

Die Hauptnavigation darf dabei nicht proportional mit der Zahl der Module wachsen.

Nicht-Ziele

• kein Marketplace in diesem Issue;
• keine Registry-Installation aus der Endnutzer-UI;
• kein neues Berechtigungsmodell;
• keine hardcodierte Liste von First-Party-Modulen;
• kein Redesign aller Fachseiten.

Akzeptanzkriterien

• Host besitzt einen stabilen Module-Einstieg.
• aktivierte Module sind suchbar und gruppiert erreichbar.
• Seiten werden eindeutig ihrem Modul zugeordnet dargestellt.
• disabled Module verschwinden aus der Navigation.
• 20+ aktivierte Module bleiben UX-seitig beherrschbar.
• AppShell/Host kennt keine konkreten Fachmodule.
• Navigation entsteht ausschließlich aus Module-SDK-/Discovery-Daten.
• Responsive-, Accessibility-, SSR- und Routing-Tests sind grün.

Parent: #108
Part of: #91
Coordinates: #136 #102