ci — arrêter les runs qui ne peuvent pas aboutir, et le doublon push+PR

Quatre runs d'une branche déjà mergée ont bloqué, ce matin, l'apply qu'on
attendait. Deux causes, indépendantes :

1. Les workflows tofu (minio, vault, crowdsec, plausible) s'authentifient à
   Vault par un flux OIDC dont un HUMAIN doit ouvrir le lien. Déclenchés tout
   seuls, ils ne peuvent qu'occuper un runner jusqu'au timeout. Ils font en
   plus `apply` en `auto_approve` CONTRE LA PROD : partir sur le push d'une
   branche, c'est appliquer du code que personne n'a relu. → `workflow_dispatch`
   seul, ce qui écrit enfin ce qu'ils faisaient déjà.

   (crowdsec et plausible passaient de toute façon par une ancre YAML, donc
   leurs triggers étaient INERTES — issues 113 → 117 de kadans.)

2. `push` sur toutes les branches + `pull_request` = DEUX runs par commit dès
   qu'une branche a une PR. Vérifié : runs 258/259 et 260/261 portent le même
   SHA. helmcharts, qui travaille seul et mérite de rester automatique, prend
   la forme éprouvée de la CI de kadans : push sur `main`, PR pour la branche.

Chaque clé de trigger porte un corps explicite : un `pull_request:` nu n'est
pas une forme éprouvée ici, et son mode d'échec est le silencieux.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA

.gitea/workflows/helmcharts.yaml

@@ -2,14 +2,32 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Helm Charts
 
-on: [push,pull_request,workflow_dispatch]
-  # push: &helmPaths # turns out gitea don't handle well the paths filter
-  #   paths:
-  #     - '*/\.yaml'
-  #     - '*/\.tpl'
-  #     - '*/NOTES.txt'
-  #     - '*/\.helmignore'
-  # pull_request: *helmPaths
+# Celui-ci travaille SEUL (pas d'auth Vault, pas d'apply) : on le garde
+# automatique. Mais `push` sur TOUTES les branches + `pull_request` faisait
+# partir DEUX runs pour le même commit dès qu'une branche avait une PR.
+#
+# Même forme que la CI de kadans : la branche est couverte par `pull_request`,
+# `main` par le `push` d'après-merge. Un run par événement, aucun angle mort.
+#
+# (Le filtre de chemins d'origine, resté en commentaire des années sous un
+# « gitea don't handle well the paths filter », n'était probablement pas en
+# cause : il passait par une ancre YAML, et le parseur d'événements de Gitea ne
+# les résout pas — issues 113 → 117 de kadans. Le job `filter-chart` fait déjà
+# ce tri au niveau job, donc on n'y retouche pas.)
+#
+# ⚠ Chaque clé porte un CORPS explicite : un `pull_request:` nu (valeur nulle)
+# n'est pas une forme éprouvée sur ce Gitea, et son mode d'échec est le
+# silencieux — aucun run, aucune erreur. On copie la forme qui tourne (kadans
+# ci.yml), listes dupliquées à la main, sans ancre.
+on:
+  workflow_dispatch: {}
+  push:
+    branches: [main]
+    paths-ignore:
+      - '**.md'
+  pull_request:
+    paths-ignore:
+      - '**.md'
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency: