Workflow : clé YAML dupliquée, plus aucun build ne partait

Depuis la fusion de la PR #21, chaque push sur main échouait en moins d'une
minute avec zéro job lancé : le YAML du workflow était devenu invalide.

La PR #21 ajoutait cache-from/cache-to après build-args, alors que le bloc
with: les portait DÉJÀ en fin de liste. Une clé dupliquée dans un mapping
YAML fait rejeter le workflow avant même son démarrage — d'où des échecs
immédiats, sans le moindre journal.

Rectification au passage : le cache n'était pas absent, il était déjà actif.
Les trente-sept minutes venaient de la nouveauté de l'étape CUDA (cache
froid) et de l'absence de borne d'architectures, corrigée elle pour de bon.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W3ewMAsXhkw9RY11kb9Dc9

.github/workflows/docker-publish.yml

@@ -54,14 +54,10 @@ jobs:
           push: true
           build-args: |
             LOKI_VERSION=${{ github.sha }}
-          # Sans cache, chaque push recompilait whisper.cpp avec CUDA — une
-          # quarantaine de minutes — alors que ce binaire ne dépend d'AUCUN
-          # fichier du dépôt. Les étapes whisperbuild-* sont désormais réutilisées
-          # tant que leurs lignes du Dockerfile ne bougent pas ; seul le code Go
-          # et l'assemblage de l'image se refont.
-          cache-from: type=gha
-          cache-to: type=gha,mode=max
           tags: ${{ steps.meta.outputs.tags }}
           labels: ${{ steps.meta.outputs.labels }}
+          # Le cache de couches réutilise les étapes whisperbuild-* (compilation
+          # whisper.cpp CUDA, ~35 min) tant que leurs lignes du Dockerfile ne
+          # bougent pas : seul le code Go et l'assemblage de l'image se refont.
           cache-from: type=gha
           cache-to: type=gha,mode=max