feat: API-Key-Auth für Krea-Endpoints (Automation ohne User-Kontext)

- AuthMiddleware: X-Api-Key Header-Prüfung für /api/images/* Routen
- Neues Config-Feld KreaApiKey in appsettings.json
- Bei gültigem API-Key wird Request ohne Cookie-Auth durchgelassen
- Normaler User-Auth funktioniert weiterhin als Fallback
- ARCHITECTURE.md + ARCHITECTURE_QUICK.md aktualisiert

ARCHITECTURE.md

@@ -368,10 +368,14 @@ Alle Endpoints folgen dem **Minimal API**-Pattern mit Extension Methods (`MapXxx
 Ausnahmen (kein Auth nötig):
 - Statische Dateien (nicht `/api/`)
 - `POST /api/auth/login`
+- `GET /api/auth/autologin` (Token-basierter Autologin via Link)
 - `POST /api/telegram/webhook/{sessionId}` (authentifiziert via Secret-Header)
 - `GET /api/shared/{token}` (öffentlicher Zugriff auf geteilte Nachrichten)
 
-Bei Erfolg werden `UserId` und `IsAdmin` in `HttpContext.Items` gesetzt.
+**API-Key Auth** (ohne User-Kontext):
+- `/api/images/*`-Routen akzeptieren einen `X-Api-Key`-Header. Wenn der Key mit `KreaApiKey` aus der Config übereinstimmt, wird der Request ohne User-Authentifizierung durchgelassen. Normaler Cookie-Auth funktioniert weiterhin als Fallback.
+
+Bei Erfolg werden `UserId` und `IsAdmin` in `HttpContext.Items` gesetzt (bei API-Key-Auth sind diese nicht gesetzt).
 
 ### Models
 
@@ -1062,7 +1066,8 @@ Die Anwendung läuft als systemd Service (`gott.service`), Kestrel auf Port 1900
   "MaxIterations": 100,         // Max Tool-Loop Iterationen pro Chat
   "PayloadLogging": false,      // API-Payloads loggen (Debug)
   "PayloadLoggingGzip": false,  // Payload-Logs als .gz komprimieren
-  "KreaToken": ""               // Krea API Token (optional)
+  "KreaToken": "",               // Krea API Token (optional)
+  "KreaApiKey": ""               // API-Key für Krea-Endpoints ohne User-Auth (optional)
 }
 ```