Add recoverable encrypted integration keys and web management

docs/integration-keys.md

@@ -0,0 +1,45 @@
+# Integrationsschlüssel
+
+Angemeldete Webnutzer finden unter **API-Schlüssel** eine eigene Verwaltungsseite.
+Programmname und mindestens ein Projekt auswählen, dann den Schlüssel erstellen.
+**Anzeigen** ruft ihn bei Bedarf erneut ab; **Verbergen** entfernt ihn aus dem
+Eingabefeld. **Kopieren** verwendet die Zwischenablage (HTTPS oder localhost).
+**Widerrufen** sperrt ihn sofort für nachfolgende API-Anfragen. Bereits laufende
+Anfragen werden dadurch nicht abgebrochen. Ein widerrufener Schlüssel wird nicht
+mehr angezeigt; für einen Ersatz einen neuen Schlüssel erstellen.
+
+Alle angemeldeten menschlichen Nutzer haben dieselben Verwaltungsrechte.
+Maschinenzugänge können weder Schlüssel verwalten noch andere Schlüssel anzeigen.
+Webmutationen einschließlich Anzeigen benötigen die vorhandene CSRF-Absicherung.
+
+Das aufrufende Programm sendet `Authorization: Bearer <Schlüssel>` an die
+Übergabe-API. Neue Schlüssel erlauben Auftragsübergabe einschließlich Rückgaben
+und lesenden Zugriff auf die ausgewählten Projekte. Sie erlauben keine
+Betriebssteuerung oder Beantwortung menschlicher Testanfragen. Zugriff auf weitere
+Projekte erfordert einen neuen Schlüssel. Bestehende env-basierte Integrationen
+bleiben unverändert nutzbar und erscheinen nicht in der SQLite-Schlüsselliste.
+
+## Speicherung und Sicherung
+
+- SQLite unter `<workspace>/runtime/integrations/keys.sqlite3` speichert Metadaten,
+  SHA-256-Prüfwerte und mit Fernet authentifiziert verschlüsselte Schlüssel.
+- Der separate Serverschlüssel entsteht beim ersten Erstellen automatisch unter
+  `<workspace>/runtime/integration-secrets/master.key`, Dateimodus 0600.
+  Nutzerkonten und ihre root-verwaltete SQLite-Datei werden nicht verändert.
+- Mit `VIANO_INTEGRATION_KEY_FILE` kann die API stattdessen eine separate
+  Schlüsseldatei verwenden. Vorhandene Dateien müssen einen gültigen Fernet-Key
+  enthalten und für den API-Dienst lesbar sein; fehlt die Datei beim ersten
+  Erstellen, muss der Dienst sie im gewählten Verzeichnis anlegen dürfen.
+- SQLite und Serverschlüssel getrennt geschützt sichern. Das Laufzeitverzeichnis
+  enthält damit dauerhaft notwendige Integrationsdaten und darf bei einer
+  Bereinigung von Sessions nicht pauschal gelöscht werden. Unter Windows passende
+  Dateisystem-ACLs verwenden; POSIX-Modusbits ersetzen dort keine ACLs.
+- Geht der Serverschlüssel verloren oder wird er unpassend ausgetauscht, können
+  Schlüssel nicht mehr angezeigt werden. Das System ersetzt ihn bei bestehenden
+  Einträgen nicht stillschweigend. Vorhandene Schlüssel können anhand ihrer
+  Prüfwerte weiterhin authentifiziert und über die Weboberfläche widerrufen werden.
+  Zur Wiederherstellung die richtige Schlüsseldatei aus der Sicherung zurückspielen.
+
+Nach einem Update die API-Abhängigkeiten neu installieren (`.[api]` umfasst jetzt
+`cryptography`) und den API-Dienst neu starten. Eine Datenbankmigration per Hand
+ist nicht nötig. Keine Änderung oder Neueingabe des Gemini-Schlüssels erforderlich.

docs/linux-deployment.md

@@ -26,6 +26,10 @@ API und Worker erhalten unterschiedliche Dateien: Nur der Worker erhält Cloud-
 und DB-Zugangsdaten. Die Diensthärtung und EnvironmentFile-Nutzung folgen der
 [systemd-Dokumentation](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html).
 
+Die [Webverwaltung für Integrationsschlüssel](integration-keys.md) ergänzt die
+env-basierte Maschinenanmeldung. Ihre SQLite und separate Schlüsseldatei müssen
+ebenfalls gesichert werden; beide liegen standardmäßig unter der Fallablage.
+
 ## Installation
 
 Den vertrauenswürdigen BugAnalysis-Checkout als root unter

docs/test-results/integration-keys-20261023.md

@@ -0,0 +1,33 @@
+# Webverwaltung für Integrationsschlüssel – 2026-10-23
+
+Ergebnis: eigene Webseite mit Programmname, Projektauswahl, Erstellen,
+erneutem Anzeigen, Verbergen, Kopieren und Widerrufen. API-Schlüssel werden
+authentifiziert verschlüsselt in separater SQLite gespeichert; die separate
+Serverschlüsseldatei wird beim ersten Erstellen angelegt. Bestehende env-Zugänge
+bleiben nutzbar. Menschliche Nutzerverwaltung unverändert ausschließlich per CLI.
+
+Lokale Prüfung ohne LLM-Aufrufe:
+
+```text
+python -m pytest tests/test_integration_keys.py tests/test_web_auth.py tests/test_deployment.py tests/test_human_web.py tests/test_dashboard.py tests/profiles/vcore/test_intake_api.py -q
+43 passed, 1 dependency deprecation warning
+node tests/dashboard-smoke.mjs
+PASS, console_errors: []
+```
+
+Abgedeckt: Session-/CSRF-Pflicht, keine Maschinenverwaltung von Schlüsseln,
+Projektbeschränkung, kein Operatorzugriff, kein Klartext in SQLite oder Listen,
+Wiederabruf nach neuer Store-Instanz, sofortiger Widerruf auch für bereits laufende
+API-Prozesse, fehlende Masterdatei ohne stille Neuerzeugung, bestehende Web-/API-
+Regressionen. Echter Headless-Edge-Test für Erstellen/Anzeigen/Verbergen/Widerrufen
+und Löschen sichtbarer Schlüsseldaten beim Logout. Kopieren nutzt die native
+Clipboard-API; deren Interaktion wurde nicht automatisiert geprüft.
+
+Die Entwicklungsversion der neuen API-Abhängigkeit cryptography wurde lokal
+installiert. Keine realen Schlüssel erzeugt oder ausgegeben; Browser nutzt
+temporäre isolierte Testdaten, die nach dem Test entfernt werden.
+Vor Testbeginn Trials 16.939.129.428 Bytes, Fehlerkorpus 2.471.041 Bytes;
+kleine synthetische Testdaten bleiben innerhalb des 20-GB-Budgets.
+
+Keine kostenpflichtigen Modellaufrufe, keine neuen Token-/Cache-/Kostenwerte.
+Kein Deployment und kein Push. Anleitung: `docs/integration-keys.md`.