capitalisation: intégration 28 entrées knowledge + 2 CLAUDE.md RL799_V2 (triage branche mcp_v1)

28 nouvelles sections intégrées dans 12 fichiers knowledge (backend risques/patterns,
frontend risques/patterns, workflow risques). Couvre rate limiting, RGPD, CSP Next.js,
refresh token TOCTOU, catch-all Prisma, distinction 401/403, tests E2E Playwright, etc.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

knowledge/backend/risques/auth.md

@@ -283,3 +283,50 @@ it('retourne 403 si subscription inactive', async () => {
 - **Signal review** : `email: user.email` dans le mapping d'un endpoint annuaire
 
 - Contexte technique : auth / annuaire — RL799_V2 02-04-2026
+
+---
+
+<a id="risque-toctou-rotation-refresh-token"></a>
+## TOCTOU sur rotation de refresh token
+
+### Risques
+
+- Un pattern `findUnique` + `update` séparés sur la rotation de refresh token crée une fenêtre TOCTOU
+- Deux requêtes concurrentes avec le même refresh token passent toutes les deux la vérification avant que l'une ne révoque → deux sessions valides émises, le vol de token passe inaperçu
+
+### Symptômes
+
+- Deux sessions actives issues du même refresh token
+- Détection de vol impossible car les deux tokens sont valides
+
+### Bonnes pratiques / mitigations
+
+- Toujours utiliser un `updateMany` atomique avec condition `WHERE revokedAt IS NULL AND expiresAt > NOW()` et vérifier `count === 1`
+- Si `count === 0`, le token a déjà été utilisé → révoquer **tous** les tokens du user (token family detection, RFC 6819)
+- **Signal review** : `findUnique` suivi de `update` séparés dans un flux de rotation de refresh token
+
+- Contexte technique : auth / refresh token — RL799_V2 08-04-2026
+
+---
+
+<a id="risque-drift-auth-copier-coller"></a>
+## Drift d'authentification par copier-coller de pattern auth
+
+### Risques
+
+- Quand un helper d'auth centralisé existe (`requireRoleAccess`), mais que de nouveaux services réimplémentent le même pattern manuellement (`extractAccessToken` + `verifyToken` + vérification locale), chaque service développe ses propres variantes (codes d'erreur différents, 401 vs 403, requestId ou non)
+- La surface d'auth devient incohérente et indéfendable en audit
+
+### Symptômes
+
+- Un audit RBAC révèle qu'une part significative des routes ont un pattern d'auth "fait maison" au lieu du helper standard
+- Codes d'erreur divergents entre services pour la même situation (token absent)
+
+### Bonnes pratiques / mitigations
+
+- Tout nouveau handler HTTP DOIT utiliser le helper centralisé pour l'authentification et l'autorisation
+- Ne JAMAIS importer `extractAccessToken` + `verifyToken` directement dans un service métier
+- Si le helper ne couvre pas un besoin (ex: besoin de `userId` en plus de `email`), étendre le helper plutôt que contourner
+- **Signal review** : import de `verifyToken` dans un fichier service (hors `authHelpers.ts`)
+
+- Contexte technique : auth / architecture — RL799_V2 08-04-2026