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.

ADMIN-Backend.md

@@ -441,9 +441,26 @@ docker compose run --rm nsct-api curl -s http://<LLM_HOST>:8030/openai/v1/models
 
 ## 5. API-Key-Verwaltung
 
-> **Hinweis:** In der aktuellen Version (Stage 22+) ist die Authentifizierung noch nicht implementiert. Die Struktur ist vorbereitet für zukünftige API-Key-Authentifizierung.
+> **Hinweis:** Research-Endpunkte unter `/v1/research/*` verlangen einen
+> `X-API-Key`. Provider-Credentials (`NSCT_LLM_API_KEY` usw.) sind davon strikt
+> getrennt und dürfen nie als Benutzer-Key verwendet werden.
 
-### 5.1 User anlegen (vorbereitete SQL-Struktur)
+### 5.1 API-Key administrieren
+
+Die Anwendung legt die Tabellen beim Start an. API-Keys werden ausschließlich
+über den lokalen Admin-CLI erstellt; der Klartext erscheint genau einmal:
+
+```bash
+nsct-api-key create --username admin --name frontend --expires-at 2027-01-31T23:59:59Z
+nsct-api-key list
+nsct-api-key revoke <key_id>
+```
+
+Den ausgegebenen Key nur im Secret-Store bzw. im Frontend speichern. Die
+Datenbank enthält ausschließlich einen gesalzenen scrypt-Hash und eine öffentliche
+`key_id`, niemals den Key selbst.
+
+### 5.2 Historische SQL-Struktur (nicht für neue Keys verwenden)
 
 Die Datenbank-Struktur für User/API-Key-Management: