feat(obs): journaliser les evenements d'authentification

OBS-001. logging_config.py configurait un fichier auth.log avec rotation,
un logger nomme 'team_tryouts.auth' et un filtre de redaction. Mais
get_auth_logger n'etait importe nulle part : le fichier etait cree et
restait vide. Aucune connexion, aucun echec, aucun verrouillage, aucun
changement de role, aucune suppression de compte ne laissait de trace.
En cas de suspicion de compromission, il n'y avait rien a consulter.

Ajout de log_auth_event(event, **fields), qui emet des paires cle=valeur
ordonnees -- greppable sans dependance de journalisation JSON.

Evenements couverts
  authentification  login.success, login.failure,
                    login.failure.unknown_user, login.rejected.locked,
                    login.rejected.deactivated, account.locked, logout,
                    account.registered
  administration    account.created_by_admin, account.updated,
                    account.role_changed (avec ancien et nouveau role),
                    account.deleted, account.password_reset_by_admin
  libre-service     account.password_changed

Le champ ip vient de request.remote_addr, donc de X-Forwarded-For. Tant que
Waitress tourne avec trusted_proxy='*' (SEC-WEB-002), cette valeur est
choisie par l'appelant : c'est une indication, pas une preuve. Le point est
documente dans la docstring.

Un test a fait remonter ARCH-003, jusqu'ici classe comme fragilite latente
  Journaliser en fin de edit_user levait DetachedInstanceError : le
  changement de role appelle db.session.remove() en plein cycle de requete,
  ce qui detache current_user de la session. Le code s'en tirait parce qu'il
  redirigeait immediatement sans plus y toucher. L'identite de l'acteur est
  desormais capturee en debut de traitement. Le constat est donc confirme
  comme reel, et non plus seulement probable -- sa correction de fond reste
  au programme.

15 tests, dont 4 sur le filtre de redaction lui-meme : c'est un controle de
securite, il doit etre verifie.

Co-Authored-By: Claude Opus 5 <[email protected]>

app/logging_config.py

@@ -172,8 +172,40 @@ def configure_logging(app):
 # Module-level auth logger factory
 def get_auth_logger():
     """Get the authentication event logger.
-    
+
     Returns:
         logging.Logger: Logger for authentication events.
     """
-    return logging.getLogger('team_tryouts.auth')
+    return logging.getLogger('team_tryouts.auth')
+
+
+def log_auth_event(event, **fields):
+    """Record a security-relevant event to auth.log.
+
+    The handler, its rotation and its redaction filter were configured from
+    the start, but get_auth_logger was never imported anywhere: auth.log was
+    created and stayed empty. No login, failure, lockout, role change or
+    account deletion left any trace.
+
+    Fields are emitted as `key=value` pairs, ordered, so the file stays
+    greppable without pulling in a JSON logging dependency.
+
+    Note on `ip`: it is taken from request.remote_addr, which reflects
+    X-Forwarded-For. As long as Waitress runs with trusted_proxy='*'
+    (SEC-WEB-002), that value is attacker-controlled and must be read as an
+    indication rather than as evidence.
+
+    Args:
+        event: Dotted event name, e.g. 'login.success'.
+        **fields: Additional context. Never pass a secret: values are
+            recorded verbatim apart from the redaction filter's patterns.
+    """
+    from flask import has_request_context, request
+
+    parts = ['event=%s' % event]
+    if has_request_context():
+        parts.append('ip=%s' % request.remote_addr)
+        parts.append('path=%s' % request.path)
+    parts.extend('%s=%s' % (key, value) for key, value in fields.items())
+
+    get_auth_logger().info(' '.join(parts))