feat: release release

[franckh-stack]

Summary

• Nouveau workflow .github/workflows/build-images.yml : build les 3 images (api, app, agent) sur push vers release (ou déclenchement manuel workflow_dispatch), push vers ghcr.io/franckh-stack/crm-{service} (latest + tag court du commit).
• Cache Docker via type=gha (cache natif GitHub Actions) — objectif : ramener le bun install (1771+ paquets, 36-41min mesurés sur vigiep1 faute de cache incrémental) à quelques dizaines de secondes sur les runs suivants.
• apps/app reçoit ses API_URL/APP_URL en build-args (https://crm.vigieproc.fr, figés une fois pour toutes — Next.js les grave dans le bundle client au build, pas au runtime, piège déjà rencontré en prod le 29/08/2026).

Pourquoi

Sur vigiep1, un rebuild complet des 3 services dépassait 2h (mesuré : crm-app ~45min, crm-agent ~70min, crm-api ~1h22 au premier build), dominé par bun install --production sur un disque I/O lent (/mnt/hermes-extra) sans aucun cache réutilisé entre builds (le Dockerfile réinstalle à froid par design, pour éviter l'incident de disque plein du 29/08). Un rebuild en parallèle des 3 services a aussi fait thrasher la RAM/swap de vigiep1 (1,3 Gi libre/7,6 Gi), en contention avec dagster/n8n/vigieproc-api qui tournent sur le même host.

Construire sur des runners GitHub dédiés élimine cette contention et permet un vrai cache incrémental.

Ce que cette PR NE fait PAS

• Ne modifie pas le docker-compose.yml de production sur vigiep1 (non versionné dans ce repo) — la bascule build: → image: + le provisionnement d'un PAT read:packages pour l'authentification à ghcr.io (registre privé) restent à faire séparément par Franck.
• Ne déclenche aucun build immédiat sur du code existant — seul un futur push vers release (ou un déclenchement manuel) lancera le premier run.

Test plan

• bun install --frozen-lockfile + push : hook pre-push complet passé (check-types, lint, lint:slop, test, 10/10 tâches turbo, 169/169 tests apps/app depuis le cache)
• Premier run du workflow non encore observé — à valider au prochain push réel vers release ou via workflow_dispatch

🤖 Generated with Claude Code

https://claude.ai/code/session_01LtJccFqpSuP8tQ3Pwg1dYH

[github-actions]

Retargeted this onto main.

release is the default branch so that a plain clone runs the last tagged release, but nothing merges into it — it is fast-forwarded onto the tag by the Release workflow and that is all. Changes go to main, and reach release when a release is cut.

Nothing is wrong with your branch. If the diff now shows commits that are already on main, rebase and force-push:

git fetch origin main
git rebase origin/main
git push --force-with-lease