Phase 0 : factorise compute_new_value + ajoute pytest/node test à la CI

1. Duplication éliminée avant que la Phase 2 (hasard/opérations
   mathématiques) n'en ajoute 6 de plus aux DEUX fichiers : la chaîne
   d'opérations quasi identique entre screens/data_actions/
   apply_data_action.py (champ d'objet) et apply_variable_action.py
   (variable globale) est factorisée dans un nouveau
   compute_operation.py::compute_new_value(operation, current, raw_value,
   is_decimal), réutilisé par les deux. Nouveau tests/test_compute_operation.py
   verrouille le comportement des 7 opérations existantes (dont les cas
   limites : valeur invalide, type décimal vs entier, opération inconnue)
   avant d'en ajouter d'autres.

2. .gitea/workflows/deploy.yml déployait en prod à chaque push sur main
   sans jamais exécuter la suite de tests — rien ne bloquait
   techniquement un commit cassé. Nouveau job "test" (pytest + node:test
   sur la logique pure de static/js/play/, via des conteneurs officiels
   plutôt que des actions du marketplace, cohérent avec le choix déjà
   fait dans ce fichier) tourne sur CHAQUE push (main ET dev, utile pour
   ce dépôt qui travaille sur dev) ; "build-and-push"/"deploy" gagnent un
   "needs: test" et restent réservés à main (filtre sur gitea.ref) — un
   push sur dev ne redéploie jamais la prod, seulement les tests.

Vérifié : 223 tests passent (8 nouveaux), YAML validé.

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

.gitea/workflows/deploy.yml

@@ -2,7 +2,14 @@ name: Build and deploy
 
 on:
   push:
-    branches: [main]
+    branches: [main, dev]
+
+# Le job "test" tourne sur CHAQUE push (main et dev) : jusqu'ici aucune
+# étape de CI n'exécutait la suite de tests, rien n'empêchait un commit
+# cassé d'atteindre la production (voir l'audit qualité de la Phase 0 du
+# plan). "build-and-push"/"deploy", eux, restent réservés à main (via le
+# filtre "if" sur gitea.ref) — un push sur dev ne doit jamais redéployer
+# la prod, seulement faire tourner les tests.
 
 # Secrets à configurer dans Gitea (Paramètres du dépôt > Actions > Secrets) :
 #   REGISTRY_HOST   adresse du registre d'images (ex: gitea.exemple.com)
@@ -19,7 +26,32 @@ on:
 # github.com / du miroir gitea.com depuis le runner self-hosted.
 
 jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      # Conteneurs officiels plutôt que actions/setup-python|setup-node du
+      # marketplace — même logique que le reste de ce fichier (éviter une
+      # dépendance à la disponibilité de github.com/du miroir gitea.com
+      # depuis le runner self-hosted), et le runner n'a pas besoin
+      # d'installer quoi que ce soit d'autre que Docker, déjà requis pour
+      # build-and-push.
+      - name: Tests Python (pytest)
+        run: |
+          docker run --rm -v "$PWD":/app -w /app python:3.13-slim sh -c "
+            pip install --quiet -r requirements-dev.txt &&
+            python -m pytest tests/ -q
+          "
+
+      - name: Tests JS (node:test — logique pure de static/js/play/, voir le plan de modularisation)
+        run: |
+          docker run --rm -v "$PWD":/app -w /app node:20-slim \
+            node --test static/js/play/__tests__/*.test.js
+
   build-and-push:
+    needs: test
+    if: gitea.ref == 'refs/heads/main'
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
@@ -41,6 +73,7 @@ jobs:
 
   deploy:
     needs: build-and-push
+    if: gitea.ref == 'refs/heads/main'
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4