[P3] Deux tests de `services` sont instables sous charge, et rendent la porte de contribution bruyante

[stephrobert]

Contexte

Deux tests de tests/test_services.py échouent par intermittence :

• test_post_start_execute_vraiment_dans_le_conteneur
• test_deux_services_se_joignent_par_leur_nom

Observés indépendamment deux fois le 2026-08-24, sur deux branches sans
rapport entre elles (#153 et #154), et dans les deux cas au hook pre-push,
c'est-à-dire quand la suite complète tourne pendant qu'autre chose sollicite
Docker.

État vérifié

$ uv run pytest                     # suite complète, machine occupée
FAILED tests/test_services.py::test_post_start_execute_vraiment_dans_le_conteneur
FAILED tests/test_services.py::test_deux_services_se_joignent_par_leur_nom
2 failed, 595 passed

$ uv run pytest tests/test_services.py -q     # seuls, machine au repos
36 passed in 9.01s

$ uv run pytest -q                            # suite complète, machine au repos
597 passed

Aucune des deux branches ne touche à runtimes/services.py ni à quoi que ce soit
qu'elles exercent. Le code n'a pas changé entre l'échec et le succès.

Ce que ça coûte

Un test rouge qui redevient vert sans qu'on ait rien fait est pire qu'un test
absent : il apprend à ne pas croire la suite. Le geste naturel devient « relance,
ça passera », et ce geste-là finit par s'appliquer à un vrai échec.

Pistes, à trancher au moment de traiter

Le point commun des deux est qu'ils attendent qu'un vrai conteneur soit prêt.
ready_tcp seul ne prouve rien sur un port publié (le proxy Docker accepte avant
que le service écoute), et c'est justement la raison d'être de ready_exec. Sous
charge, le délai d'attente est le suspect naturel :

• mesurer d'abord ce qui expire : ready_timeout, le démarrage du conteneur,
  ou l'attente d'un post_start. Le message d'échec devrait le dire tout seul,
  et s'il ne le dit pas, c'est le premier défaut à corriger ;
• allonger un délai est la correction la plus tentante et la moins informative :
  elle déplace le seuil sans dire ce qui était lent. À ne faire qu'après la mesure ;
• vérifier qu'ils ne partagent pas un nom de conteneur ou un réseau avec un autre
  test, auquel cas c'est une collision, pas un délai.

Critères d'acceptation

• La cause est mesurée, pas supposée : on sait quelle attente expire.
• Les deux tests passent quand la machine est chargée (à reproduire en jouant
  la suite pendant qu'un autre travail sollicite Docker).
• Un échec de ces tests nomme ce qui n'était pas prêt, plutôt que de rendre
  une assertion nue.

Priorité et lot

P3. Rien n'est cassé dans le produit : le défaut est dans la mesure. Mais il
touche la porte de contribution, donc tout le monde, et il s'aggrave en confiance
perdue plutôt qu'en symptôme.