feat(client): retentatives automatiques par défaut des erreurs retentables

[arsenik-dtheo]

Closes #8
Partie de l'épic #6

🔍 Ce que fait cette PR

Le client HTTP retente automatiquement les erreurs retentables (429, 529, 5xx) : par défaut 2 retries, soit 3 tentatives au total, sans aucune configuration. Le délai entre tentatives suit un backoff exponentiel partant de 0,5 s, doublé à chaque tentative et plafonné à 8 s, avec jitter. À épuisement des tentatives, l'erreur d'origine est levée ; les erreurs non retentables (401, 403, 404, 422) échouent immédiatement, sans rejeu. La requête POST est rejouée à l'identique (corps et headers générés une fois). Les retentatives sont silencieuses (v1). Typesafe::Jev hérite du comportement.

✅ Critères couverts

• Un appel qui reçoit 429 puis 200 (ou 529/5xx puis 200) réussit et renvoie la réponse attendue, avec exactement 2 tentatives au total → spec/typesafe/client_spec.rb, scénarios 429→200 / 529→200 / 500→200, have_been_requested.times(2) + matcher corps/headers prouvant le rejeu à l'identique
• Au-delà de 2 retries (3 échecs retentables), l'erreur d'origine (RateLimitError, OverloadedError ou ServerError) est levée → scénarios d'épuisement, .times(3) requêtes, erreur d'origine assertée
• Un 422 (ou 401/403/404) n'est jamais rejoué : une seule requête, erreur levée immédiatement → .once sur les 4 statuts non retentables
• Les délais demandés entre tentatives suivent la politique : base 0,5 s, doublement, plafond 8 s, avec jitter → stub de Kernel.sleep, bornes assertées [0,25 ; 0,5] puis [0,5 ; 1,0] ; le plafond 8 s n'est pas observable avec les défauts (nominaux max 1,0 s à 2 retries), il sera exercé par le ticket 04 (max_retries configurable)
• Par défaut, aucun réglage n'est nécessaire → tous les scénarios utilisent un Client.new nu ; héritage Jev testé (spec/typesafe/jev_spec.rb)

👀 Comment vérifier

1. bundle exec rspec spec/typesafe/client_spec.rb — les scénarios de retentatives montrent les séquences de requêtes et les délais demandés au stub de sommeil
2. En vrai : un client confronté à un 429 transitoire réussit sans intervention de l'appelant, là où la v0 nécessitait une boucle manuelle

🧪 Vérifications

• Seam de test : Typesafe::Client#evaluate / Typesafe::Jev#evaluate (WebMock sur l'endpoint + stub de sommeil) — cf. ## Décisions de test de la spec
• typecheck propre (ruby -c sur lib + spec)
• suite complète verte (219 exemples, 6 seeds)
• diff contenu dans le périmètre du ticket (pas de Retry-After, pas de ConnectionError, pas de retry_options: — tickets 02/03/04)

⚠️ Écarts et arbitrages

Signalements [NIT] de la revue, non bloquants, non corrigés ici :

• À épuisement, le code lève la dernière erreur ; une séquence mixte (429 → 529 → 500) n'est pas épinglée par un test — tests homogènes uniquement
• Le plafond 8 s est unreachable avec les défauts (max_retries = 2 → nominal max 1,0 s) : code mort jusqu'au ticket 04
• AGENTS.md énonce déjà « Retry-After honoré » et « retry_options: sur Client.new » : contrats à venir, pas encore dans le code (tickets 02 et 04)
• L'exemple de README.md (§ erreurs) et la docstring APIError enseignent encore un rescue RateLimitError → sleep → retry manuel, qui se cumule désormais avec les retentatives automatiques — à réécrire au ticket 05 (documentation)
• spec/typesafe/client_spec.rb (contexte « errors ») : le stub de sommeil masque que ces tests font désormais 3 requêtes ; un .times(3) explicite garderait l'intention lisible

📚 Références

• Ticket : 01 : retentatives par défaut des erreurs retentables #8 · Épic : retry-client: retentatives automatiques dans le client HTTP #6
• Spec : docs/plans/retry-client/spec.md
• Branche : epic-6-docs ← epic-6/01-retentatives-defaut