ci(adk): config/test_providers.py ne tourne dans aucune jambe -- le job adk-contracts ne lance qu'un fichier #20002

Part of #13504

Le fait (mesuré)

MyIA.AI.Notebooks/ML/DataScienceWithAgents/Track2-GoogleADK/config/test_providers.py ne tourne dans aucune jambe de CI.

Trois mesures :

1. Le job dédié ne lance qu'un fichier. .github/workflows/scripts-tests.yml l. 557 (adk-contracts, name: ADK runtime contracts (18)) invoque pytest sur un seul chemin — Track2-GoogleADK/utils/test_adk_runtime_contracts.py — avec un plancher de collection de 18 (l. 592+). config/test_providers.py n'y figure pas.
2. Le déclencheur tire déjà, la collection manque. Le job est déclenché sur Track2-GoogleADK/** (l. 87, miroir sous pull_request:). Déplacer config/ arme donc le job — sans que le fichier soit exécuté. La surface CI existe ; c'est la collecte qui est absente, et son absence est silencieuse (aucun rouge, aucune trace).
3. Les testpaths racine ne le couvrent pas. pytest.ini porte, pour la famille DataScienceWithAgents, MyIA.AI.Notebooks/ML/DataScienceWithAgents/01-PythonForDataScience/tests uniquement.

Même classe que #15058 (contrats C4-C7 hors de toute jambe, résolu en câblant le job adk-contracts) et que #10903 / #18888 (suites invisibles), mais instance distincte : ce n'est pas le même répertoire ni la même suite que ce que #15079 a câblé.

Pourquoi ce n'est pas une lacune de couverture ordinaire

La suite est l'invariant qui lie les défauts déclarés de Settings aux DEFAULTS de ProviderConfig. Le défaut de #14755 est né précisément là : un identifiant de modèle OpenRouter retiré du catalogue a survécu comme défaut dans Settings, parce que rien ne comparait les deux — get_provider_config résout settings.<p>_model or defaults["model"], et le repli n'est exercé que si la variable d'environnement est vide. Les deux valeurs divergent alors sans bruit.

Le test ajouté par la PR #19972 (commit 3c4c42b770) ferme cette classe de défaut. Tant que le fichier n'est pas collecté, la fermeture est déclarative : elle a été mesurée à la main (32 tests verts), et rien ne rougira si elle régresse.

Câblage naturel, et le piège de pin

Le bon hôte est le job adk-contracts lui-même, et non la liste pytest partagée de scripts-tests :

• config/test_providers.py n'importe que pytest, pathlib, importlib.util ; config/providers.py n'importe que pydantic + pydantic_settings — aucun litellm ni google-adk au niveau module, contrairement aux contrats C1-C7 qui ont motivé l'env isolé de feat(ci,#15058): ADK contracts — brancher les 16 tests C1-C7 dans un job dedie (litellm installe, job isole) #15079 ;
• cet env installe déjà pydantic==2.12.5 + pydantic-settings + python-dotenv : le coût d'hébergement y est nul.

Le piège à ne pas sauter : le job épingle pydantic==2.12.5, alors que la PR #19972 a été mesurée localement sous 2.13.4. Le témoin négatif repose sur la réassignation de FieldInfo.default ; il doit être rejoué sous le pin du job avant de câbler, sinon le câblage peut rougir pour une raison d'environnement et non de contrat.

Critères d'acceptation

1. config/test_providers.py est exécuté par une jambe de CI (le job adk-contracts étant l'hôte attendu).
2. Un plancher de collection l'accompagne, sur la sémantique des planchers existants du même fichier (contrats 18, audit 455, secrets 148, GradeBook 15) : 0 collecté = crash de collecte, sous le plancher = régression de couverture, jamais du ménage.
3. Le câblage est validé par un run à la tête d'une PR touchant le fichier, sous le pin du job (pydantic==2.12.5), avec le nombre de tests relevé au run et non au poste de l'auteur.

Provenance

Relevé comme « observation distincte préexistante » dans la review 5463813094 de la PR #19972 (le défaut du test introduit y étant traité séparément, au commit 3c4c42b770). Le mandat de review demandait explicitement de ne pas prétendre une enforcement CI et de « câbler l'invariant dans la jambe adaptée ou ouvrir un suivi nommé » : c'est cette seconde branche, l'écart de pin ci-dessus rendant le câblage non trivial à vérifier dans la PR de correction du test.