fix(api): erzwungenen Passwortwechsel an der API wirklich durchsetzen

JwtStrategy.validate liess mustChangePassword auf dem Weg vom Token zu
request.user fallen; der global registrierte ForcePasswordChangeInterceptor
prueft genau dieses Feld und hat seit seiner Einfuehrung nie etwas
blockiert. validate() reicht das Feld jetzt durch (strenger Vergleich mit
true, Alt-Sitzungen ohne den Anspruch bleiben unveraendert unbetroffen).

Zusaetzlich die Erlaubnisliste des Abfangers von Teilstring-Vergleich auf
exakten Abgleich von Methode UND Pfad umgestellt (Absicherung gegen eine
kuenftige kollidierende Route, heute nicht ausnutzbar).

Nahttest gepinnt, der gegen den alten Quelltext nachweislich scheitert
(6 von 12 neuen Faellen rot vor der Aenderung, gruen danach).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J

apps/api/src/auth/strategies/jwt.strategy.ts

@@ -30,6 +30,10 @@ export class JwtStrategy extends PassportStrategy(Strategy) {
       username: payload.username,
       role: payload.role,
       tenantId: payload.tenantId,
+      // Ein vor dieser Aenderung ausgestelltes Token traegt diesen Anspruch
+      // nicht; der strenge Vergleich ergibt dann false, laufende Sitzungen
+      // verhalten sich unveraendert (260921-fi3, D-01 — keine Aussperrwelle).
+      mustChangePassword: payload.mustChangePassword === true,
     };
   }
 }