Implement persistent API-key authentication

Protect the research lifecycle with X-API-Key validation backed by persistent user and key records. Store only salted scrypt hashes, support expiry and revocation, and expose a local admin CLI for create/list/revoke workflows.

Initialize only the authentication schema at startup, prevent SQL echo from exposing sensitive bound values, and keep health probes public. Add coverage for valid, missing, invalid, expired, and revoked keys.

Document deployment and key administration, update the local CLI to send NSCT_API_KEY, and record the reset handoff state.

HANDOFF.md

@@ -43,31 +43,27 @@ Relevante gepushte Commits:
 - Frontend `c6f1889` — Dokumentation für getrennte Deployments.
 - Backend `9830acf` — Dokumentation für Frontend-Integration auf separatem Host.
 
-### Nächste Aufgabe: echte API-Key-Authentifizierung
+### API-Key-Authentifizierung — implementiert, Deployment ausstehend
 
-Die Authentifizierung ist aktuell **nicht implementiert**. Das Frontend speichert
-einen eingegebenen Key im `localStorage` und sendet `X-API-Key`, aber das Backend
-prüft diesen Header nicht. Die in `.env` gesetzten `NSCT_LLM_API_KEY`,
+`/v1/research/*` prüft jetzt `X-API-Key`; `/health` und `/ready` bleiben für
+Infrastruktur-Probes öffentlich. Die in `.env` gesetzten `NSCT_LLM_API_KEY`,
 `NSCT_VISION_API_KEY` und `NSCT_AUDIO_API_KEY` sind ausschließlich Credentials
 für externe Modellanbieter — niemals als Benutzer- oder Frontend-Keys verwenden.
 
-Empfohlene Umsetzung in diesem Repository:
+Die Datenbank enthält User, Schlüssel-Metadaten, eine öffentliche `key_id` sowie
+einen individuellen, langsamen scrypt-Hash — keinen Klartext-Key. Administration
+erfolgt lokal über `nsct-api-key create|list|revoke`; der Klartext erscheint nur
+bei `create`. Die CLI nutzt für Research-Aufrufe optional `NSCT_API_KEY`.
 
-1. Ein Auth-Modul als FastAPI-Dependency ergänzen, das `X-API-Key` prüft.
-2. Eine persistente User-/API-Key-Tabelle per Migration/Schema anlegen; nur einen
-   starken, langsamen Hash speichern, niemals den Klartext-Key.
-3. Einen administrativen CLI-Workflow für Erstellen, Auflisten, Ablauf und
-   Widerruf implementieren. Kein Key-Management-Endpunkt ohne separate Admin-
-   Authentifizierung.
-4. `/health`, `/ready` und ggf. `/docs` bewusst als öffentlich oder geschützt
-   festlegen; alle Research-Endpunkte konsistent schützen.
-5. Tests für gültige, fehlende, ungültige, abgelaufene und widerrufene Keys
-   ergänzen. Erst danach im Frontend Login/API-Fehlerbild verifizieren.
+Vor dem Deployment einen Key erzeugen und als Frontend-Key hinterlegen:
 
-Vor der Implementierung zuerst die vorhandenen SQL-Beispiele in
-`ADMIN-Backend.md`, die tatsächlichen SQLAlchemy-Modelle und die FastAPI-Router
-abgleichen: Die Dokumentation beschreibt derzeit nur eine vorbereitete Struktur,
-keine aktive Authentifizierung.
+```bash
+docker compose exec nsct-api nsct-api-key create --username admin --name frontend
+```
+
+Die Implementierung ist durch Tests für gültige, fehlende, ungültige, abgelaufene
+und widerrufene Keys abgedeckt. Nach dem nächsten Container-Rebuild das
+Frontend-Fehlerbild für HTTP 401 prüfen.
 
 ---