feat(platform): add audit logs and activity feed

CONTRIBUTING.md

@@ -64,6 +64,8 @@ Eine Aenderung gilt erst als fertig, wenn diese Punkte erfuellt sind:
 - `npx next build --webpack` erfolgreich in `frontend/athena`
 - `python3 -m compileall backend/hermes/app` erfolgreich im Projektroot
 - Alembic-Migrationen geprueft, falls Datenbankschema betroffen ist
+- `uv run alembic history` erfolgreich in `backend/hermes`
+- `uv run alembic upgrade head` erfolgreich in `backend/hermes`, wenn Migrationen betroffen sind
 - Docker Compose startet
 - keine `.env` im Git
 - keine `node_modules` im Git
@@ -85,6 +87,12 @@ npx next build --webpack
 python3 -m compileall backend/hermes/app
 ```
 
+```bash
+cd backend/hermes
+uv run alembic history
+uv run alembic upgrade head
+```
+
 ## Coding Standards
 
 ### Frontend
@@ -94,6 +102,7 @@ python3 -m compileall backend/hermes/app
 - Browser-API-Zugriffe nur ueber Athena `/api/...`.
 - Wiederverwendbare Komponenten bevorzugen.
 - UI-Zustaende immer abbilden: Loading, Error, Empty State.
+- Erfolg und Fehler in mutierenden CRUD-Flows ueber den Toast-Provider melden.
 - Keine Browser-Dialoge wie `alert()` oder `confirm()`.
 - Keine Tokens in Browser-JavaScript speichern.
 
@@ -107,6 +116,8 @@ python3 -m compileall backend/hermes/app
 - Nicht gefundene Ressourcen als `404 Not Found`.
 - Authentifizierung serverseitig pruefen.
 - Berechtigungen mit `require_permission`, `require_any_permission` oder `require_all_permissions` pruefen.
+- Mutierende Kernaktionen mit Audit Logs erfassen, sofern fachlich relevant.
+- Sensible Felder vor Persistenz in Logs oder Audit-Daten maskieren.
 
 ### Allgemein
 
@@ -130,6 +141,8 @@ Diese Regeln sind verbindlich:
 - Keine Cross-Origin-Cookie-Loesungen.
 - RBAC wird serverseitig in Hermes durchgesetzt.
 - Frontend-Permissions dienen nur der UI und ersetzen keine Backend-Pruefung.
+- Audit Logs werden serverseitig in Hermes geschrieben.
+- Neue Plattform-Endpunkte sollen das einheitliche API-Response-Format nutzen.
 
 Wenn eine Aufgabe diese Regeln zu verletzen scheint, muss zuerst die Architekturentscheidung geklaert werden.
 
@@ -151,6 +164,7 @@ Verbindliche Wiederverwendung:
 - `ConfirmDialog` fuer destruktive Aktionen
 - `SearchInput` fuer Suchfelder
 - `StatusBadge` oder aehnliche Badge-Komponenten fuer Statusanzeigen
+- `ToastProvider` fuer Erfolg und Fehler bei mutierenden Aktionen
 - `api` Client aus `frontend/athena/lib/api.ts`
 - Athena API-Routes als BFF-Schicht
 - konsistente Fehlerbehandlung
@@ -177,6 +191,7 @@ Ein neues CRM-Modul soll sich am Kundenmodul orientieren:
 - Frontend-Seiten unter `frontend/athena/app/<module>`
 - wiederverwendbare UI-Komponenten unter `frontend/athena/components`
 - RBAC-Permissions vor der UI-Integration definieren
+- Audit-Log-Ereignisse fuer relevante Create/Update/Delete-Aktionen definieren
 - keine Fake-Daten fuer noch nicht existierende Unterbereiche
 
 Dashboard-Widgets fuer noch nicht implementierte Module muessen Empty States anzeigen statt hart codierter Beispieldaten.
@@ -228,6 +243,9 @@ Vor Merge pruefen:
 - keine neuen CORS- oder Cookie-Workarounds
 - Permission-Pruefung fuer neue Endpunkte vorhanden
 - Permission-UI nur als Komfort, nicht als Sicherheitsgrenze
+- Audit Logs fuer relevante Aenderungen vorhanden
+- API-Fehlerantworten konsistent
+- Toasts fuer mutierende UI-Aktionen vorhanden
 
 ## Migrationsregeln