chore(ci): aligner `yarn check` et la CI sur les mêmes vérifications

[arenier]

De quoi il s'agit

Le garde-fou local (yarn check) et le garde-fou d'intégration (.github/workflows/ci.yml) doivent
vérifier la même chose, pour qu'un yarn check vert ne puisse jamais casser la CI et réciproquement.
yarn check est le critère bloquant écrit noir sur blanc dans #10, #12 et #18, et CLAUDE.md le
présente comme « lint + format + typecheck + test + build sur tous les projets ».

La situation a évolué depuis la rédaction initiale de ce draft. À l'état 74bc516 relevé alors,
ni l'un ni l'autre n'était un sur-ensemble de l'autre. Depuis, le commit 9e4aa72 (#40, align the
check gate with CI on format and typecheck) a ajouté oxfmt --check et typecheck à yarn check.
Il ne reste donc qu'un seul écart : la CI ne lance pas build.

État actuel (HEAD 9e4aa72)

yarn check (package.json) :

oxlint --type-aware && oxfmt --check && nx run-many -t lint typecheck test build

Étape Checks de la CI (.github/workflows/ci.yml) :

yarn oxlint --type-aware
yarn format:check
yarn nx affected -t lint typecheck test

Vérification	yarn check (run-many, tous projets)	CI (nx affected)
oxlint --type-aware	✅	✅
oxfmt --check	✅	✅
lint (ESLint, frontières Nx)	✅	✅
typecheck	✅	✅
test	✅	✅
build	✅	❌

yarn check est désormais un sur-ensemble de la CI. La seule différence assumée qui subsiste est
la sélection des projets — run-many (tout) en local, affected en CI — et c'est le bon choix :
inutile de passer la CI en run-many (voir Hors périmètre).

Le seul écart restant : build absent de la CI

Conséquence concrète : une CI verte peut casser le build. targetDefaults.test porte
dependsOn: ["^build"] (nx.json) — les dépendances d'un projet sont donc bâties avant ses
tests, mais le projet lui-même ne l'est jamais en CI. Une régression propre au build (config
vite.config.mts cassée, lib qui ne compile pas via tsc) passe l'intégration et n'est rattrapée
que par un yarn check local — que rien n'impose de lancer — ou plus tard au déploiement. C'est
exactement le prérequis que #32 (pipeline de build/push d'image) suppose réglé ici et ne veut pas
dupliquer.

Décisions à acter

1. Garantie de non-divergence. run-many et affected interdisent une commande unique, mais la
   liste des cibles Nx (lint typecheck test build) et les deux étapes Oxc doivent rester
   identiques des deux côtés. Approche recommandée : un garde-fou exécutable qui échoue si les deux
   listes divergent, dans l'esprit du check « toolchain pins agree » déjà présent dans ci.yml
   (lignes 84-117). Option minimale : un commentaire croisé explicite dans les deux fichiers.
   À trancher.
2. Coût du job. Ajouter build à nx affected allonge le job check ; le surcoût est à mesurer
   (avant/après, sur un affected non trivial) et à juger acceptable.

Critères d'acceptation

• L'étape Checks de la CI exécute build : yarn nx affected -t lint typecheck test build.
• La liste des cibles Nx vérifiées est identique entre yarn check et la CI ; seule la
  sélection des projets (run-many vs affected) diffère, et c'est documenté.
• Un mécanisme empêche la re-divergence des deux listes (garde-fou exécutable retenu, ou a
  minima commentaire croisé — selon la décision actée ci-dessus).
• Le garde-fou est démontré opérant, dans l'esprit des deux tests de CLAUDE.md (import
  interdit, void manquant) : casser un build (ex. erreur dans un vite.config.mts ou une
  lib) et constater que la CI échoue là où elle passait ; réparer, la CI repasse au vert.
• CLAUDE.md (section CI) est mis à jour : nx affected -t lint typecheck test build.
• Le surcoût du job est mesuré et reporté dans la PR.

Découpage en tâches

1. Ajouter build à la commande nx affected de l'étape Checks dans .github/workflows/ci.yml.
2. Mettre en place la garantie de non-divergence retenue (garde-fou exécutable de préférence).
3. Mettre à jour CLAUDE.md (section La CI… : ajouter build à la liste) et le README si besoin.
4. Vérifier le garde-fou par un rouge/vert jetable (build cassé → CI rouge → réparé → CI verte).
5. Mesurer et reporter le surcoût du job.

Hors périmètre

• Passer la CI en run-many. Le choix affected est le bon (base calculée par
  nrwl/nx-set-shas) — non rouvert ici.
• Le pipeline de build/push d'image applicative — c'est ci(cd): pipeline de build et de déploiement d'image — Artifact Registry puis Cloud Run #32. Cette issue lui fournit le prérequis
  « build vérifié en CI » sans le dupliquer.
• Rendre le job terraform bloquant / requis — c'est le constat annexe de ci(infra): instruire l'automatisation du terraform plan/apply — plan relu, apply derrière approbation #33.

Dépendances

Aucune : package.json (scripts) et .github/workflows/ci.yml. Recoupe #21 (automate de mise à
jour des dépendances) sur le fichier CI, sans dépendance logique — #21 s'appuiera sur un garde-fou
correct, donc autant faire celle-ci d'abord.

Références

package.json (script check), .github/workflows/ci.yml (étape Checks, et le check
« toolchain pins agree » comme modèle de garde-fou), nx.json (targetDefaults, plugins),
ADR 0007 (Vite/Vitest partout), ADR 0008 (oxlint/oxfmt, ESLint réduit aux frontières),
CLAUDE.md (sections Commandes et CI), #40 (a déjà aligné format:check et typecheck),
#32 (consommateur du build vérifié en CI).