perf(picker): mutualiser la tête du tapis sur un dashboard -- 648 s à froid, 258 s à chaud, calcul refait par chaque machine #20053

Constat (mesuré le 2026-10-09 sur ai-01, main = 7de6984058)

python scripts/pick_idle_grain.py --belt --lane myia-ai-01:CoursIA :

Les deux dépassent le timeout d'environ 120 s des outils shell des agents, qui se plaignent de la durée du picker. Le 2026-10-07, po-2026 mesurait 123 s à froid (#19643) : l'outil a ralenti depuis. Le cache existant (gh_payload_cache, %LOCALAPPDATA%/CoursIA/cache/pick_idle_grain, TTL de 10 à 60 min) est local à chaque machine et pèse ~134 Mo (pool 3,3 Mo, visites 14,5 Mo, séries jusqu'à 49,5 Mo). Chaque machine refait donc le même calcul, et même à chaud, 258 s ne sont pas couvertes par le cache : ce sont les sondes par candidat (livraison, claims, état des PRs).

Le calcul est identique pour toutes les lanes, à un filtre par lane près.

Proposition (question du user, 2026-10-09 : « est-ce que ça ne pourrait pas être mutualisé sur les dashboards ? »)

1. Un classement publié, pas des payloads. Les payloads (~70 Mo) ne tiennent pas dans un dashboard (plafond ~50 Ko). Ce qui se partage, c'est le résultat : la tête du tapis (~50 issues), avec par issue le numéro, la famille, la date de dernière visite, le verdict de livraison, le claim vivant au moment du calcul, et l'horodatage UTC du calcul. Taille visée : < 10 Ko.
2. Transport : section status d'un dashboard dédié (CoursIA-belt), sur le modèle déjà en service de CoursIA-gpu-reservation-ledger (debt_ledger.py : le script imprime l'appel MCP, l'agent l'exécute ; la lecture se fait sur l'export du dashboard). Pas d'écriture sous $ROOSYNC_SHARED_PATH.
3. Producteur : le coordinateur à chaque cycle, plus toute lane qui recalcule à froid (écriture traversante). Le coût est alors payé une fois par période de validité pour toute la flotte, au lieu d'une fois par machine et par lane.
4. Consommateur : pick_idle_grain.py --board-export <export.json> --lane X applique le filtre de lane, puis un seul contrôle vivant (check_lane_claim.py) sur le candidat retenu. Le claim reste le verrou : deux lanes qui lisent la même tête se départagent par le claim, comme aujourd'hui. Si l'instantané a plus de N minutes (60 par défaut), retour au calcul local, et le résultat est republié.
5. Articulation avec feat(coordination): tirage central du tapis par le coordinateur + tour de recette hebdomadaire par lane #19492 (tirage central par le coordinateur, files profondes par lane) : les files dispatchées restent la source principale. Le classement publié sert la réserve, c'est-à-dire une lane dont la file est vide entre deux cycles du coordinateur (4 h).

Acceptance

• Profil du --belt chaud : où vont les 258 s (sondes par candidat, appels gh par issue). Chiffres cités.
• Mode producteur : écrit le classement (schéma versionné, horodatage UTC, < 10 Ko) et imprime l'appel MCP de publication.
• Mode consommateur --board-export : < 15 s de bout en bout sur un instantané frais, retour au calcul local au-delà de la période de validité, contrôle vivant du claim sur le candidat retenu.
• Tests hors ligne (instantané frais, périmé, malformé, candidat claimé entre-temps).
• Ligne de catalogue dans docs/reference/scripts-reference.md. Le câblage dans continue.md / la skill coordinate est un changement de harnais : PR séparée.

Voir #18832 (tapis), #19492 (tirage central), #19643 et #20021 (robustesse et isolement réseau du picker), #19236 (cache par tranche).