feat: extend module platform with UI slots, runtime components, CLI tooling and {{userId}} search support

Completes the generic module platform that enables modules to contribute
UI elements, runtime JS components, and search resources without any
core hardcoding.

New generic UI slot types:
- topbar.right_item: module-contributed topbar buttons
- layout.body_end_template: module-contributed dialog/overlay templates
- layout.head_style: module-contributed global CSS
- runtime.component: declarative JS component registration with phase ordering

New infrastructure:
- ModuleAutoloader: PSR-4 autoloading for module-local PHP classes
- ModuleRuntimePageBuilder: symlinks module pages into runtime directory
- ModuleRuntimeAssetPublisher: publishes module CSS/JS to web/modules/
- ModulePermissionSynchronizer: syncs module permissions to DB
- CLI scripts: module-runtime-sync, module-build, module-migrate,
  module-permissions-sync, module-assets-sync
- {{userId}} placeholder in SearchDataService for user-scoped search queries
- Component runtime with phased initialization (early/default/late)
- AppContainer.protectExistingBindings() to prevent module→core overwrites
- Architecture tests: ModuleStructureContractTest, CoreTemplateIsolationTest,
  FrontendComponentRuntimeContractTest, AppContainerIsolationContractTest

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/reference-extension-readiness.md

@@ -1,41 +1,57 @@
-# Extension-Readiness (ohne Architektur-Festlegung)
+# Extension-Readiness (Module-System V1.1)
 
-Letzte Aktualisierung: 2026-03-09
+Letzte Aktualisierung: 2026-03-18
 
 ## Ziel
 
-Verbindliche Vorbedingungen fuer spaetere eigenstaendige Module festhalten, ohne jetzt eine konkrete Extension-Mechanik (Hooks/Lifecycle/Loader) zu standardisieren.
+Verbindliche Vorbedingungen fuer weitere eigenstaendige Module auf dem bestehenden Modul-System festhalten.
 
-## Readiness-Checkliste vor neuem Modul
+## Kanonische Quelle
+
+Normativer Manifest- und Runtime-Contract: `/docs/reference-module-manifest-contract.md`.
+
+Diese Readiness-Doku ist bewusst kurz und verweist fuer Felddefinitionen/Guards immer auf den Manifest-Contract.
+
+## Readiness-Checkliste vor Modul 2+
 
 1. **Modulgrenzen klarziehen**
    - Betroffene Schichten benoennen (`pages -> Service -> Repository`).
-   - Keine SQL-/Business-Logik in Templates oder `pages/*.phtml`.
-2. **Contracts definieren**
-   - Oeffentliche API-/UI-Contracts dokumentieren (Inputs, Outputs, Fehlerfaelle).
-   - Bei API-Aenderungen `docs/openapi.yaml` im selben Merge pflegen.
+   - Keine Modul-spezifischen Hardcodings im Core-Layout/Core-Routing.
+2. **Manifest-Contract einhalten**
+   - `module.php` validiert gegen den kanonischen Contract (`permissions`, `scheduler_jobs`, `ui_slots`, `routes`).
+   - Route-/Slot-/Layout-Guards laufen fail-fast.
 3. **Security + Scope absichern**
    - AuthZ/RBAC serverseitig pruefen.
    - Tenant-Scope serverseitig pruefen.
    - POST-Mutationen mit CSRF absichern.
-4. **Testbarkeit und Gates**
+4. **Runtime-Hygiene absichern**
+   - `php bin/module-runtime-sync.php` laeuft reproduzierbar mit standardisierter Step-Summary.
+   - Keine First-party CLI-Warnings/Notices/Deprecations; Vendor-Rauschen wird nur gezaehlt/reportet.
+5. **Testbarkeit und Gates**
    - Architektur- und Domain-Tests fuer neue Logik ergaenzen.
-   - Relevante Quality Gates (`QG-*`) im Merge reporten.
-5. **Daten- und Betriebsfaehigkeit**
+   - `phpunit` und `phpstan` als Pflicht-Gates gruen.
+6. **Daten- und Betriebsfaehigkeit**
    - Schema-/Datenaenderungen fuer Bestandsinstallationen idempotent in `db/updates/*.sql`.
    - Logs/Audit ohne unredacted PII/Secrets.
 
-## Bewusst Out of Scope in diesem Stand
+## Derzeit Out of Scope
 
-- Kein standardisierter Extension-Loader.
-- Kein Hook-/Plugin-Lifecycle.
-- Keine verbindlichen Modul-Ablageorte ausserhalb bestehender Schichten.
+- Eigener DB-Server oder Netzwerk-Microservice je Modul.
+- Externe Drittanbieter-Module mit Legacy-Kompatibilitaet.
 
-## Entscheidungslog fuer spaetere Standardisierung
+## Verfuegbare Core-Services fuer Module
 
-Wenn die Extension-Mechanik spaeter konkretisiert wird, muss die Entscheidung mindestens diese Punkte mitliefern:
+JS-seitig:
 
-1. Aktivierung/Deaktivierung und Reihenfolge von Modulen.
-2. Versionierung und Migrationsstrategie pro Modul.
-3. Sicherheits- und Tenant-Isolation pro Erweiterung.
-4. Test- und Rollback-Strategie fuer Modul-Deployments.
+- Confirm-Dialog (`confirmDialog`)
+- Async-Flash (`showAsyncFlash`)
+- DOM-Utilities (`app-dom.js`)
+- CSRF-Metadaten über `data-csrf-key` / `data-csrf-token`
+
+PHP-seitig:
+
+- Guard (`MintyPHP\\Support\\Guard`)
+- SessionStore (`MintyPHP\\Http\\SessionStoreInterface`)
+- Flash (`MintyPHP\\Support\\Flash`)
+- DI-Container (`MintyPHP\\App\\AppContainer`)
+- Modul-Contracts (`LayoutContextProvider`, `SessionProvider`, `SearchResourceProvider`)