Limiteur de tentatives sur /auth/login et /auth/magic-link

Suite de la revue de sécurité (commit précédent) : ni /auth/login (mot
de passe COORDINATION) ni /auth/magic-link n'avaient de limite de
tentatives — aucun verrou de compte, aucun throttling, avant ouverture
au public.

`app/auth/rate_limit.py` : limiteur en mémoire (un seul processus
uvicorn, cf. Dockerfile), à créneau glissant, par clé (édition, email)
plutôt que par IP — le VPS ne transmet pas encore l'IP réelle du
client à travers Caddy, et le risque réel ici est de deviner le mot de
passe d'un compte connu (peu de comptes protégés par mot de passe),
pas une attaque distribuée sur des emails au hasard.

- `/auth/login` : 5 tentatives/minute → 429 `error.too_many_requests`.
- `/auth/magic-link` : 3 demandes/5 min (évite aussi le spam d'emails
  vers une victime ou vers le SMTP).

Fixture `_reset_rate_limiters` (autouse) pour ne pas faire fuiter l'état
d'un test à l'autre. Testé : dépassement, indépendance des clés,
expiration de la fenêtre, scénarios bout en bout sur les deux
endpoints.

Non inclus dans ce commit (édités en parallèle par l'utilisateur, laissés
en l'état) : backend/app/seed.py, frontend/tailwind.config.js.

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

deploy/README.md

@@ -33,9 +33,11 @@ serveur** (service système, hors de ce dépôt) reçoit le trafic public sur
   même origine via `/api/*` (voir le vhost Caddy, étape 5) — à ne renseigner
   que si un autre client (domaine séparé, appli mobile) doit appeler l'API
   directement.
-- Aucun rate-limiting sur `/auth/login` ni `/auth/magic-link` à ce stade
-  (pas de verrouillage de compte, pas de throttling) — acceptable pour une
-  petite équipe connue, mais à surveiller si l'URL circule plus largement.
+- `/auth/login` et `/auth/magic-link` sont limités en tentatives par email
+  (5/min et 3/5 min) — voir `app/auth/rate_limit.py`. Limité par email et
+  non par IP (le VPS ne transmet pas encore l'IP réelle du client à travers
+  Caddy) : suffisant contre la force brute sur un compte connu, pas contre
+  une attaque distribuée sur de nombreux emails différents.
 
 ## Étape 0 — pousser le dépôt sur GitLab