ci: PR gate FAILURE en rafale — quota GitHub App épuisé (HTTP 403 installation), distinct de #13363 (pool)

[jsboige]

Mesure (24/09, 3 lanes indépendantes)

Burst de FAILURES de PR gate sur motif infrastructure — gh: API rate limit exceeded for installation. ... (HTTP 403) — le quota de l'installation GitHub App du dépôt est épuisé côté serveur, distinct du quota utilisateur (po-2024 : core 5000/5000 OK).

• po-2026, 13:30Z : 7 PRs gate FAILURE en 3 min (13:25:02→13:27:33Z) — feat(secrets,#16755): centraliser la cle medium vLLM (VLLM_API_KEY_MEDIUM -> TGWUI_MEDIUM_API_KEY) #17667, feat(genai-audio,#17586): Phase A0 bakeoff_small infra + 4 client skeletons #17661, fix(lean,#17576): Lean-16a re-execute sur lake chaud — les 5 #eval de la section 3.7 rendent leurs valeurs #17663, docs(encyclique,#11359): mise à jour du dialogue avec Magnifica Humanitas #17664, fix(lean,#17612): _run_wsl uses lean --json with Init.Prelude wrapper (not repl) #17621, fix(perco,#17508): Percolation-Supercritique — trois claims recadrés sur les sorties exécutées #17657, fix(sl,#17600): SL-9 cellule 17 — strip du titre markdown collé par le gateway CoT + re-exec LLM réel #17602. Échantillon vérifié (feat(secrets,#16755): centraliser la cle medium vLLM (VLLM_API_KEY_MEDIUM -> TGWUI_MEDIUM_API_KEY) #17667, job 107634105357) : 5 retries × 30 s épuisés sur 403. Tous les checks ayant pu tourner : verts — aucun verdict de contenu.
• po-2024, 14:05Z : fix(lean,#17576): Lean-16a re-execute sur lake chaud — les 5 #eval de la section 3.7 rendent leurs valeurs #17663 re-rerun 13:31Z → 6 transient read failures consécutives → FAILURE. File réparation po-2024 à 15/15 (plafond WIP) : plusieurs PRs dépendent du gate.
• po-2025 (lane CoursIA), 14:31Z : feat(complexity): accessible time hierarchy 03 and Hartmanis-Stearns 03b #17662 attempt 2 → FAILURE, même 403 (« 6 transient read failure(s) in a row »).

Congestion de pool adjacente (couverte par #13363) : #17674 38 checks queued, #17663 28, #17667 3.

Pourquoi une nouvelle issue

• CI: un tiers des runners tenu par 'PR gate' en attente — les correctifs #11405 et #11770 sont en tension et personne ne possede l'arbitrage #13363 = saturation des runners (pool) ; ici c'est le quota API de l'installation — le gate ne peut même pas LIRE l'état des checks. Remèdes distincts.
• CI: pr-gate-rerun lit une tentative 'queued' morte comme 'en vol' et saute -- PR READY bloquee sans rouge #17680 = bug du rerun (lit queued comme en vol) — adjacent, non couvrant.
• Cause probable citée par po-2024 : flambée d'appels API concurrents ce matin (cycles d'inventaire multi-machines), le quota installation étant partagé entre sessions/workflows actives.

Pistes (à arbitrer)

1. Instrumenter le quota installation — gh api rate_limit côté user ne l'expose pas ; demande po-2024 14:05Z à ai-01 sans réponse à 14:30Z (cycle coord 5h en cours).
2. Backoff adaptatif du gate sur 403 rate-limit : 5 retries × 30 s sont dérisoires face à un reset horaire — auto-report (re-run planifié) plutôt que FAIL.
3. Limiter les appels gh concurrents sur ce dépôt pendant les cycles multi-machines (sérialisation ou espacement des tirs d'inventaire).

Geste lane en attendant : rerun post-DWELL uniquement, jamais re-push (po-2026 13:30Z).

Sources : dashboard global 24/09 13:30Z (po-2026) et 14:05Z (po-2024) ; trace locale po-2025:CoursIA 14:31Z.

[jsboige]

Grain: MED/guard — lane myia-po-2025:CoursIA — prev: DEEP/notebook-python #17960
[CLAIMED] lane myia-po-2025:CoursIA -- paths: scripts/pr_gate.py, scripts/tests/test_pr_gate_transient_retry.py, scripts/tests/test_pr_gate.py -- corriger le traitement du quota installation GitHub App dans le gate, sans vert fictif ni dépassement de la deadline.

[myia-ai-01]

Fermeture — urne delivered, vérifiée sur origin/main par ai-01 (05/10)

Livrée par #17987. Le gate reconnaît strictement la famille du quota d'installation (INSTALLATION_QUOTA_MARKERS, scripts/pr_gate.py). Il applique pour elle un backoff dédié (30, 120, 300, 600 puis 900 s, au lieu de 5 fois 30 s), et son FAIL nomme la famille, pour qu'on ne la prenne pas pour une panne de contenu. Les tests sont dans scripts/tests/test_pr_gate_transient_retry.py, section #17681. Les pistes 1 et 3 du body étaient marquées « à arbitrer » et sortent de l'acceptance.