feat(repairs): add status timeline and public link preparation

ARCHITECTURE.md

@@ -204,9 +204,11 @@ Kernfunktionen:
 - Reparaturen manuell anlegen und bearbeiten
 - eindeutige Reparaturnummer im Format `R<jahr>-<laufende nummer sechsstellig>`, z. B. `R2026-000001`
 - Statusmodell von `new` bis `completed` oder `cancelled`
+- deutsche UI-Statuslabels in Athena, die internen API-Statuscodes bleiben englisch und stabil
 - Statushistorie in `repair_status_history`
-- Audit Logs fuer Erstellung, Bearbeitung, Statuswechsel, Storno und Intake
-- Dashboard-Kennzahlen fuer neue Reparaturen, Diagnose, wartende Kundenfreigaben und abgeschlossene Reparaturen
+- werkstattgerechte Status-Timeline mit Datum, Benutzer und Notiz
+- Audit Logs fuer Erstellung, Bearbeitung, Statuswechsel, Storno, Intake und Statuslink-Verwaltung
+- Dashboard-Kennzahlen fuer neue Reparaturen, Diagnose, wartende Kundenfreigaben, laufende Reparaturen, Endpruefung und abgeschlossene Reparaturen
 
 Tabellen:
 
@@ -214,6 +216,8 @@ Tabellen:
 - `repair_status_history`
 - `repair_intake_events`
 - `repair_documents`
+- `repair_public_access_tokens`
+- `repair_notification_events`
 
 Hermes-Endpunkte:
 
@@ -224,9 +228,66 @@ Hermes-Endpunkte:
 - `DELETE /repairs/{id}` als fachliches Storno
 - `PUT /repairs/{id}/status`
 - `GET /repairs/{id}/history`
+- `GET /repairs/{id}/public-link`
+- `POST /repairs/{id}/public-link`
+- `DELETE /repairs/{id}/public-link`
+- `GET /repairs/{id}/notifications`
+- `GET /public/repairs/status/{token}`
 
 Athena-BFF-Routen spiegeln diese Endpunkte unter `/api/repairs...`. Mutierende Athena-Routen behalten die Same-Origin-Pruefung bei.
 
+Statuslabels:
+
+```text
+new = Neu
+accepted = Angenommen
+diagnosis = Diagnose
+estimate = Kostenvoranschlag
+waiting_for_customer = Wartet auf Kunde
+approved = Freigegeben
+repair = Reparatur
+final_test = Endprüfung
+ready_for_pickup = Abholbereit
+shipped = Versand
+completed = Abgeschlossen
+cancelled = Storniert
+```
+
+### Sicherer Reparaturstatus-Link
+
+v0.8.1 bereitet einen oeffentlichen Statuslink vor. Es wird noch kein Kundenportal und kein Kundenlogin gebaut.
+
+Sicherheitsmodell:
+
+- Klartexttoken wird lang und zufaellig erzeugt.
+- In PostgreSQL wird nur ein HMAC/SHA-256-Hash des Tokens gespeichert.
+- Der Klartexttoken wird nur einmal bei Erstellung an Athena zurueckgegeben.
+- Tokens werden niemals geloggt.
+- `repair_public_access_tokens` speichert Aktivstatus, Ablaufdatum, letzte Nutzung und Widerruf.
+- `GET /public/repairs/status/{token}` gibt nur kundenfreundliche Statusdaten aus.
+- Keine Kundendaten, internen Notizen oder Diagnosedetails werden oeffentlich ausgegeben.
+
+Die spaetere Website kann daraus einen Pfad wie `/status/<token>` anbieten. Die eigentliche Website wird in Olympus nicht veraendert.
+
+### Reparatur-Benachrichtigungen
+
+`repair_notification_events` bereitet nachvollziehbare Kundenkommunikation vor. Der Versand wird noch nicht erzwungen.
+
+Vorbereitete Ereignisse:
+
+- Reparatur erfasst
+- Geraet angenommen
+- Diagnose laeuft
+- Kostenvoranschlag erstellt
+- Wartet auf Kundenfreigabe
+- Reparatur laeuft
+- Endpruefung
+- Abholbereit
+- Versand
+- Abgeschlossen
+
+Vorlagen enthalten deutsche Betreffzeilen und Texte mit Platzhaltern fuer `repair_number`, `customer_name`, `device`, `status_label`, `public_status_url` und `company_name`.
+
 ### Website Repair Intake
 
 Hermes stellt `POST /public/repair-intake` fuer eine spaetere serverseitige Website-Anbindung bereit.
@@ -241,7 +302,7 @@ Sicherheitsmodell:
 
 Der Intake speichert immer ein `repair_intake_events`-Ereignis und erzeugt bei erfolgreicher Verarbeitung einen Reparaturdatensatz mit `source = website` und `status = new`.
 
-Eine spaetere Kundenportal-Statusseite ist architektonisch vorbereitet, aber noch nicht oeffentlich implementiert.
+Eine spaetere Statusseite ist architektonisch vorbereitet, aber noch nicht in der oeffentlichen Website implementiert.
 
 ## RBAC: Rollen und Berechtigungen