revert(ci): rétablit le ciblage des runners par nom

[BryanFRD]

🚨 Revert urgent de #187 et #191. À fusionner sans attendre : tout dépôt qui monte son épingle vers ces SHA voit ses jobs bloqués indéfiniment.

Ce qui se passe

runs-on: group=ferrlabs-k8s ne fonctionne pas avec les runner scale sets ARC. Preuve d'exécution, sur un job Astro de FerrLabs/Status :

Requested labels: group=ferrlabs-k8s
Waiting for a runner to pick up this job...

GitHub interprète group=ferrlabs-k8s comme un label demandé, et non comme un sélecteur de runner group. Or les runners ARC s'enregistrent sans aucun label :

$ gh api orgs/FerrLabs/actions/runners --jq '.runners[0] | {name, labels}'
{"labels": [], "name": "ferrlabs-k8s-large-sw8dg-runner-9hjn9"}

Aucun runner ne peut donc satisfaire la demande. Le job attend pour toujours — sur les deux sites, production comprise. Ce n'est pas un problème de répartition : c'est un runs-on qui ne matche rien.

La syntaxe group= appartient au modèle des runners auto-hébergés classiques, qui portent labels et groupe. Pour ARC, la documentation est explicite : runs-on prend le nom d'installation du scale set, et ne mentionne aucune syntaxe group=.

Contenu

Les 30 occurrences reviennent au ciblage par nom ('ferrlabs-k8s'). Le commentaire de garde du job integration est corrigé : il invoquait un mécanisme de group qui n'existe pas ; il énonce désormais la vraie contrainte — ce job dépend de postgres-ci, interne au cluster de production, et ne doit jamais être routé ailleurs.

Impact constaté

Seul FerrLabs/Status avait monté son épingle (Status#138) et a des jobs bloqués. Les autres dépôts pointent encore l'ancien SHA et ne sont pas affectés — la lenteur de propagation par Renovate a limité la casse.

Après fusion : relancer les exécutions bloquées de Status, ou attendre que son épingle repointe un SHA sain.

Le fond du problème reste entier

Le runner group ferrlabs-k8s (id 9) contient bien les deux scale sets — production (id 12) et Homelab (id 13), contrôleurs alignés en 0.10.1. Mais un runner group ne distribue pas les jobs entre scale sets : il sert au contrôle d'accès (quels dépôts peuvent utiliser ces runners), pas au routage.

La capacité d'appoint du Homelab demande donc un autre mécanisme. Piste à instruire, documentée par GitHub : « runner scale set names are unique within the runner group they belong to. To deploy multiple scale sets sharing the same name, they must be in different runner groups. » Deux scale sets portant le même nom dans des groups différents pourraient répondre au même runs-on: ferrlabs-k8s — reste à vérifier si GitHub répartit réellement dans ce cas, ce qui n'est documenté nulle part et devra être testé.

[ferrfleet]

Mechanical revert, matches the stated root cause (ARC scale sets register with no labels, so group= is parsed as an unsatisfiable label selector rather than a group selector).

Verified: searched main for remaining group=ferrlabs-k8s occurrences — the 11 files/13 matches found are exactly the ones this diff touches, so the revert is complete, no strays left behind. The reworded guard comment on the integration job in reusable-ci-rust.yml correctly restates the real constraint (postgres-ci is only reachable from the production scale set) without the incorrect "group" framing. No blocking issues.