Simplifie les événements : notification pure, sans paramètre

Retour de l'utilisateur sur le premier jet : "Déclencher un événement"
ne doit JAMAIS faire choisir un élément — c'est une notification pure,
rien de plus. C'est à l'ÉCOUTEUR (déclencheur "Sur un événement
personnalisé" → condition → action) de décider quoi faire ensuite, avec
ses réglages habituels (cible fixe, "Ligne cliquée"...), jamais à
l'événement de transporter un paramètre.

Retire donc tout le mécanisme de transmission ajouté au tour précédent
(has_element_param, target_element_from_event, EVENT_ROW_ID,
window.lastEventParams) :

- db/custom_events/ : _custom_events perd sa colonne has_element_param —
  un événement n'est plus qu'un nom + une description.
- screens/flow/ : retire target_element_from_event (colonne ajoutée par
  ALTER TABLE, laissée inerte sur les bases déjà migrées — sans
  conséquence, plus jamais lue ni écrite) et la constante EVENT_ROW_ID.
- routes/flow/flow_node_run_data.py : retire la résolution EVENT_ROW_ID,
  revient à sa forme d'origine (seul CLICKED_ROW_ID reste géré).
- templates/screen_edit.html : le nœud Action "Déclencher un événement"
  n'a plus qu'un sélecteur d'événement — plus de champs élément/ligne.
  Le nœud Action "Modifier un élément" perd la case "Utiliser l'élément
  transmis par l'événement en cours". L'onglet Événements perd la case
  à cocher "Paramètre" (création et édition).
- templates/play.html : window.dispatchGameEvent(eventId) ne prend plus
  que l'id de l'événement — scan global inchangé, mais ne pose plus
  aucun window.lastEventParams. modifier_element et readFieldValue
  reviennent à leur résolution d'origine (plus de branche event-aware).

208 tests au total (2 tests retirés, devenus sans objet : la
persistance de target_element_from_event et la résolution serveur
d'EVENT_ROW_ID).

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

screens/flow/constants.py

@@ -21,16 +21,6 @@
 # AUTOINCREMENT SQLite).
 CLICKED_ROW_ID = -1
 
-# Même principe que CLICKED_ROW_ID, pour un second contexte dynamique :
-# "la ligne de Répéteur transmise par l'événement personnalisé en cours
-# d'exécution" (voir screens/custom_events/, nœud Déclencheur
-# trigger_event="evenement") — stockable directement dans target_row_id
-# (déjà sans contrainte de clé étrangère, voir ensure_flow_schema.py) au
-# même titre que CLICKED_ROW_ID, résolu côté client (templates/play.html)
-# via window.lastEventParams.row_id au lieu de window.lastClickedRowId.
-# Valeur distincte de CLICKED_ROW_ID pour ne jamais les confondre.
-EVENT_ROW_ID = -2
-
 TRIGGER_EVENTS = [
     ("clic", "Au clic"),
     ("soumission", "À la soumission"),
@@ -89,14 +79,11 @@ FLOW_NODE_FIELDS = {
     "target_variable",
     # Événements personnalisés (voir screens/custom_events/) : quel
     # événement un nœud Déclencheur écoute (trigger_event="evenement") ou
-    # un nœud Action déclenche (action_type="declencher_evenement") —
-    # target_element_id/target_row_id (déjà ci-dessus, EVENT_ROW_ID
-    # compris) portent les paramètres transmis au déclenchement.
-    # target_element_from_event : indicateur réutilisable par N'IMPORTE
-    # QUEL nœud Action qui accepte déjà target_element_id (v1 : seule
-    # "modifier_element" le supporte) — contourne la contrainte de clé
-    # étrangère de target_element_id (impossible d'y stocker un sentinel
-    # comme EVENT_ROW_ID sur target_row_id) en résolvant "l'élément
-    # transmis par l'événement en cours" côté client à la place.
-    "trigger_custom_event_id", "target_custom_event_id", "target_element_from_event",
+    # un nœud Action déclenche (action_type="declencher_evenement") — un
+    # événement est une pure NOTIFICATION, sans paramètre : "déclencher"
+    # ne fait que signaler, jamais choisir un élément. C'est à l'ÉCOUTEUR
+    # (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",
 }