fix(auth): JWT nicht als API-Key prüfen (Bearer-Fallback nur für pm_-Keys)

Beim JWT-Ablauf fällt der JwtOrApiKeyGuard auf den ApiKeyGuard zurück. Dieser
nahm bisher jedes Authorization-Bearer-Token als API-Key-Kandidaten – also auch
das (abgelaufene) JWT – und loggte eine irreführende "Invalid API Key"-Warnung
(samt JWT-Präfix). Der Bearer-Fallback akzeptiert nun nur noch Token mit dem
API-Key-Präfix "pm_"; ein JWT wird ignoriert. Ergebnis bleibt 401 (Frontend
re-authentifiziert), aber ohne irreführenden Log.

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

paperless-backend/src/auth/api-key.guard.ts

@@ -28,12 +28,19 @@ export class ApiKeyGuard implements CanActivate {
       if (apiKey) source = 'apiKey query param';
     }
 
-    // Fallback to Authorization: Bearer (used by SSE clients that can't set X-API-Key)
+    // Fallback to Authorization: Bearer (used by SSE clients that can't set
+    // X-API-Key). Nur akzeptieren, wenn das Token wie ein API-Key aussieht
+    // (Präfix "pm_"). Ein (abgelaufenes) JWT als Bearer-Token wird hier ignoriert,
+    // statt es fälschlich als API-Key zu prüfen – das vermeidet die irreführende
+    // "Invalid API Key"-Warnung beim normalen JWT-Ablauf.
     if (!apiKey) {
       const auth: string | undefined = request.headers['authorization'];
       if (auth?.startsWith('Bearer ')) {
-        apiKey = auth.slice(7);
-        source = 'Authorization: Bearer';
+        const token = auth.slice(7);
+        if (token.startsWith('pm_')) {
+          apiKey = token;
+          source = 'Authorization: Bearer';
+        }
       }
     }