Schlüssel-Proxy, Server-Anforderungen und gitleaks-Regel für API-Werk

- tools/ki-proxy: setzt API-Schlüssel aus der Windows-Anmeldeinformationsverwaltung ein,
  nur im Speicher, ohne Header-Protokoll; Tests gegen Platzhalter-Server
- docs/server-anforderungen.md für den ITM-Entwickler
- .gitleaks.toml erkennt zki_/zodl_/zocr_-Schlüssel
- CLAUDE.md, Plan, Tech-Stack: Schlüssel nie in .env, in der App verschlüsselt in der DB

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

docs/tech-stack.md

@@ -63,10 +63,11 @@ Redis wird nicht eingesetzt: Warteschlange, Cache und Sessions laufen über die
 | Passkeys | WebAuthn über Fortify | ergänzt |
 | API-Authentifizierung | – | Sanctum vorerst nicht nötig (keine eigene API) |
 | Verschlüsselung sensibler Werte | Verschlüsselte Casts, u. a. für Zugangsdaten der KI-API | gleich |
+| Schlüssel der KI-API | Nie in `.env`: verschlüsselt in der Datenbank, in der Oberfläche nur beschreibbar; in der Entwicklung Schlüssel-Proxy mit Windows-Anmeldeinformationsverwaltung (`tools/ki-proxy`) | ergänzt |
 | Transport | HTTPS/TLS | gleich |
 | Formularschutz | CSRF, serverseitige Validierung | gleich |
 | Protokollierung | Verwaltungsaktionen (Upload, Rechte, Freigaben) und technische Logs | gleich |
-| Geheimnisse im Code | gitleaks als Pre-Commit-Hook | ergänzt |
+| Geheimnisse im Code | gitleaks als Pre-Commit-Hook, eigene Regel für API-Werk-Schlüssel (`.gitleaks.toml`) | ergänzt |
 | Keine externen Ressourcen | Test prüft alle Seiten auf fremde Hosts | ergänzt (Vorgabe „alles lokal“) |
 
 Rechte werden an den Zugriffswegen und an den auslösenden Aktionen geprüft, zusätzlich bei