feat(datenbank): Datenmodell mit Datenbankregeln und Seed (#003)

Alle Modelle fuer die fuenf Phasen in einer Migration, damit spaetere
Phasen keine Umbauten an Kerntabellen brauchen. Was auch an der
Service-Schicht vorbei gelten muss, steht als CHECK, partieller Index
oder Trigger in der Datenbank: Personen-Keys ohne Private Key, genau
ein Instanz-Deployment-Key, ein vertrauter Host-Key je Algorithmus,
shell-sichere Zielbenutzer und Pfade.

Das Protokoll ist append-only und per Hash-Kette verbunden; den Hash
berechnet ein Trigger, damit keine Zeile ohne Verkettung entstehen
kann (#005 baut darauf auf).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/issues/003-datenmodell.md

@@ -1,23 +1,28 @@
 # #003 Datenmodell und Migrationen
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.1.0
 **Labels:** datenbank
-**Geschätzt:** 3 h   **Tatsächlich:** –
+**Geschätzt:** 3 h   **Tatsächlich:** 0 h 10 min
 
 ## Ziel
 Prisma-Schema für alle Phasen (Hosts, Gruppen, Personen, Schlüssel, Verwendungen, Host-Keys, Vorgänge, Protokoll), erste Migration, Seed.
 
 ## Aufgaben
-- [ ] Schema mit deutschen Bezeichnern (siehe `CLAUDE.md`)
-- [ ] Datenbankregeln (CHECK, Trigger) für das, was auch an der Service-Schicht vorbei gelten muss
-- [ ] Seed: Notfall-Admin, eingebaute Vorlagen, optional Demo-Daten
-- [ ] Test-Datenbank-Setup für Vitest
+- [x] Schema mit deutschen Bezeichnern (siehe `CLAUDE.md`)
+- [x] Datenbankregeln (CHECK, Trigger) für das, was auch an der Service-Schicht vorbei gelten muss
+- [x] Seed: Notfall-Admin, eingebaute Vorlagen (Demo-Daten folgen mit #008)
+- [x] Test-Datenbank-Setup für Vitest
 
 ## Akzeptanzkriterien
-- [ ] Migration läuft auf leerer Datenbank
-- [ ] Tests für die Datenbankregeln
+- [x] Migration läuft auf leerer Datenbank
+- [x] Tests für die Datenbankregeln
 
 ## Abhängigkeiten
 #001
 
 ## Notizen / Entscheidungen
+- **Protokoll-Hash in der Datenbank berechnet** (Trigger), nicht in der Anwendung: so kann niemand eine Zeile ohne Verkettung einfügen. Die ID wird erst unter einer Advisory-Sperre vergeben, sonst bricht die Kette bei gleichzeitigem Schreiben (Test mit 20 parallelen Einträgen).
+- **TRUNCATE des Protokolls** nur mit `SET LOCAL sshkv.test_modus = 'ja'` – ausschließlich für die Testhilfe. Ein Datenbank-Superuser kann Trigger immer abschalten; dagegen hilft die Hash-Kette (Prüfung findet die manipulierte Zeile) und später der Syslog-Export (#027).
+- **Zielbenutzer, Adresse und Private-Key-Pfad per CHECK eingeschränkt:** Diese Werte landen in Shell-Skripten auf den Hosts. Quotierung bleibt Pflicht, aber was gar nicht erst in die Datenbank kommt, kann nichts anrichten.
+- **TOTP-Geheimnis mit `SSHKV_APP_SECRET` verschlüsselt,** nicht mit dem Master-Key: geprüft wird es im Webprozess, und der Master-Key bleibt im Worker.
+- Ein Host-Key-Wechsel ist eine neue Zeile `AUSSTEHEND` neben der vertrauten; je Host und Algorithmus höchstens ein vertrauter Key (partieller Index).