Test: No-Stranding-Gate fuer Provider-Fallback-Routing + Doku-Praezisierung

findFallbackProviderNotInCooldown-Charakterisierungstest sichert den Invariant
ab, auf dem der Routing-Fix (986fbab) seine Sicherheit aufbaut: bei kein
Cooldown den ersten Provider, bei einem Cooldown den naechsten gesunden, und
NULL erst wenn ALLE Provider im Cooldown sind. Dieses null ist der Punkt, an
dem der Aufrufer queueRetry statt Reorder macht — wuerde der Helper hier je
einen abgekuehlten Provider als letzten Notnagel zurueckgeben, liefe der
Reorder am Sicherheitsnetz vorbei. Der Test friert das ein.

Zusaetzlich: entscheidungen-offen.md praezisiert, dass Option A des Failover-
Timeouts ein Drehregler ueber den Pro-Provider-Wert ist (30s/90s, 60s/180s),
kein fixer Wert.

tasks/entscheidungen-offen.md

@@ -26,10 +26,12 @@ trifft in der Produktion derzeit selten. Deshalb dokumentiert statt dringend gef
 
 **Deine Entscheidung — zwei Richtungen (gleiche Spannung, andere Seite):**
 
-- **A) Pro-Provider-Timeout:** Jeder Provider bekommt sein eigenes frisches 60s-Budget.
+- **A) Pro-Provider-Timeout:** Jeder Provider bekommt sein eigenes frisches Budget.
   Failover bekommt IMMER einen echten Versuch.
-  *Kosten:* Worst-Case-Wartezeit pro Item steigt (3 Provider × 60s = bis zu 180s, bevor ein
-  Item aufgibt). Du akzeptierst langsameres Worst-Case-pro-Item für vollständigeres Failover.
+  *Kosten:* Worst-Case-Wartezeit pro Item steigt. Das Budget ist dabei ein DREHregler, kein
+  fixer Wert: 60s/Provider = bis 180s Worst-Case (3 Provider), 30s/Provider = bis 90s usw.
+  Du akzeptierst langsameres Worst-Case-pro-Item für vollständigeres Failover — und stellst
+  über den Pro-Provider-Wert ein, wie viel langsamer.
 
 - **B) Globales Budget behalten, aber Slice für Failover reservieren:** Provider 1 wird auf
   z.B. 35s gedeckelt, damit garantiert Zeit für Provider 2 bleibt.