Phase 3 : hardening qualite de code - typage strict, securite, dead code, a11y

Config strictement stricte partout (ruff, mypy --strict, bandit, vulture,
import-linter, eslint, stylelint), aucune regle desactivee "pour ne pas
casser le build" - l'existant a ete corrige pour la satisfaire plutot que
l'inverse. Hooks pre-commit locaux (language: system) bloquants.

- Typage mypy --strict propage a tout le moteur (db, screens, auth, core,
  ai, routes, puis publish/scripts/tests/app.py/build_css.py).
- Securite : fuite de handle fichier Windows corrigee dans l'export SCORM
  (routes/publish/export_scorm.py), CSRF/RNG non-crypto/xAPI documentes
  (# nosec, # NOSONAR justifies), nouveau db.json_for_script() (echappe
  "</script>" dans le JSON embarque en <script>, 25 sites).
- Architecture : imports circulaires/F811 nettoyes, contrats
  import-linter respectes, code mort retire (vulture).
- Accessibilite : 69 champs de formulaire sans label correctement
  associe corriges (for/id ou aria-label) sur 11 templates.
- ESLint/Stylelint : lot mecanique JS/CSS, regles ajustees puis
  appliquees (aucune desactivee sans verification individuelle).
- Tests : isolation du compte admin partage (nettoyage ponctuel +
  fixture de teardown automatique en filet de securite), suite complete
  verte (591 tests Python, 241 tests JS).
- SonarQube Community Build self-heberge (Docker + PostgreSQL) : rapport
  complet analyse point par point, faux positifs documentes.
- .gitattributes ajoute (LF force) : core.autocrlf=true sur cette machine
  faisait echouer ESLint (linebreak-style) via un bug connu de git
  (checkout "en place" qui ignore l'eol force sur un fichier deja
  present sur disque - contourne en supprimant puis recreant chaque
  fichier suivi).

djLint (H021, styles inline) volontairement saute pour ce commit -
backlog assume, deja documente, traite dans un lot separe.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

screens/flow/constants.py

@@ -103,19 +103,36 @@ CONDITION_OPERATORS = [
 CONDITION_OPERATOR_LABELS = dict(CONDITION_OPERATORS)
 
 FLOW_NODE_FIELDS = {
-    "trigger_element_id", "trigger_event",
-    "cond_definition_id", "cond_row_id", "cond_field", "cond_field_type", "cond_operator", "cond_value",
+    "trigger_element_id",
+    "trigger_event",
+    "cond_definition_id",
+    "cond_row_id",
+    "cond_field",
+    "cond_field_type",
+    "cond_operator",
+    "cond_value",
     # 2.4 — conditions combinées (ET/OU) : cond_clauses est une liste JSON de
     # clauses supplémentaires (en plus de la clause "historique" ci-dessus,
     # qui reste la première clause) + cond_combinator ('et'/'ou') pour savoir
     # comment les combiner. Absents => comportement legacy (une seule clause).
-    "cond_clauses", "cond_combinator",
+    "cond_clauses",
+    "cond_combinator",
     # Condition sur une VARIABLE GLOBALE plutôt qu'un champ d'objet — voir
     # ensure_flow_schema.py pour le détail des 3 clés (cond_source vaut
     # "objet" ou "variable" ; absent => "objet", comportement historique).
-    "cond_source", "cond_variable", "cond_variable_chemin",
-    "action_type", "target_screen_id", "target_element_id", "element_property", "element_value",
-    "target_definition_id", "target_row_id", "target_field", "data_operation", "data_value",
+    "cond_source",
+    "cond_variable",
+    "cond_variable_chemin",
+    "action_type",
+    "target_screen_id",
+    "target_element_id",
+    "element_property",
+    "element_value",
+    "target_definition_id",
+    "target_row_id",
+    "target_field",
+    "data_operation",
+    "data_value",
     "target_variable",
     # Événements personnalisés (voir screens/custom_events/) : quel
     # événement un nœud Déclencheur écoute (trigger_event="evenement") ou
@@ -125,7 +142,8 @@ FLOW_NODE_FIELDS = {
     # (déclencheur → condition → action) de décider quoi faire ensuite,
     # avec ses propres réglages habituels (target_element_id normal, pas
     # de mécanisme dynamique dédié).
-    "trigger_custom_event_id", "target_custom_event_id",
+    "trigger_custom_event_id",
+    "target_custom_event_id",
     # Blocs de logique (voir screens/flow/blocks/) : à quel bloc ce nœud
     # appartient. Aucun `update_flow_node` n'existe (éditer un nœud le
     # recrée puis supprime l'ancien) — le client doit donc renvoyer
@@ -133,14 +151,17 @@ FLOW_NODE_FIELDS = {
     "block_id",
     # Phase 3 — déclencheur clavier ("clavier") et minuteur récurrent
     # ("minuteur"), voir TRIGGER_EVENTS ci-dessus.
-    "trigger_key", "trigger_interval_ms",
+    "trigger_key",
+    "trigger_interval_ms",
     # Phase 5 — condition de collision (cond_source="collision", aux
     # côtés de "objet"/"variable") : les deux éléments dont on compare les
     # rectangles — voir evaluateConditionClause() dans
     # static/js/play/conditions.js.
-    "cond_element_a", "cond_element_b",
+    "cond_element_a",
+    "cond_element_b",
     # Fondations multi-éditeurs — jeux "jeu_2d" : équivalents de
     # trigger_element_id/target_element_id pour un objet de scène (voir
     # ensure_flow_schema.py).
-    "trigger_object_id", "target_object_id",
+    "trigger_object_id",
+    "target_object_id",
 }