fix(eu): Kapazitaetsengpaesse bei Bedrock aussitzen statt Schritte verlieren

Am 01.08.2026 lieferte Bedrock waehrend eines Laufs ServiceUnavailableException.
Botocore versuchte es dreimal in fuenf Sekunden und gab auf, die
Web-Source-Selektion fiel ersatzlos aus. Im Bericht war davon nichts zu sehen,
der Lauf galt als vollstaendig. Gemessen sind es zwei betroffene Aufrufe bei
rund 340, also 0,6 Prozent, aber jeder Vorfall kostet einen ganzen
Pipeline-Schritt.

Der Fehler ist auch keiner unserer Quote. ServiceUnavailableException ist ein
503, AWS hat also gerade keine Kapazitaet fuer das Modell. Unsere Meldung
sagte trotzdem "Rate-Limit", weil der Code beide Faelle in einen Topf warf.

Aendert sich damit:

1. Geduldiges Wiederholen. Kapazitaets- (503), Kontingent- (429) und
   Verbindungsfehler werden nach 5, 15 und 30 Sekunden erneut versucht. Diese
   Dellen dauern typischerweise unter einer Minute, unsere bisherigen fuenf
   Sekunden lagen genau im ungeguenstigsten Fenster. Stufen ueber
   BEDROCK_RETRY_WAITS einstellbar.

2. Zwei Bremsen gegen lange Laeufe. Gewartet wird nur, wenn die Wartezeit ins
   Zeitbudget des Aufrufs passt (die Wartezeit zaehlt gegen dasselbe
   asyncio-Budget, und die Haiku-Planungsaufrufe haben nur 120 Sekunden), und
   nur solange das Wartebudget des Refreshs reicht (BEDROCK_RETRY_BUDGET_S,
   Vorgabe 120 Sekunden). Ein Lauf kann sich dadurch um hoechstens zwei
   Minuten verlaengern.

3. Ursachen werden getrennt benannt. Im Log steht jetzt "hat keine freie
   Kapazitaet" oder "meldet ausgeschoepftes Kontingent" statt pauschal
   "Rate-Limit". Nach aussen bleibt beides die Kategorie rate_limit, damit die
   Retry-Steuerung des Orchestrators unveraendert greift.

4. Stoerungen werden sichtbar. Waehrend einer Wartezeit meldet die Oberflaeche
   "KI-Dienst hat keine freie Kapazitaet, neuer Versuch in 15 Sekunden", sonst
   sieht die stehende Anzeige wie ein Haenger aus. Nach dem Lauf steht eine
   Zusammenfassung im Refresh-Protokoll, auch wenn der Lauf sonst glatt
   durchlief.

5. botocore laeuft im Modus 'adaptive' statt 'standard'. Es bremst sich bei
   Drosselung selbst ein und deckt die Sekunden ab, unsere Schleife die
   Zehnersekunden.

Zeitliche Wirkung, gemessen am EU-Lauf der Ceuta-Lage (252 Sekunden, 15
Bedrock-Aufrufe): im stoerungsfreien Fall null, im betroffenen Lauf rund eine
Minute mehr. Bei 0,6 Prozent Fehlerrate je Aufruf trifft das etwa jeden
elften Lauf, im Mittel ueber alle Laeufe rund zwei Prozent.

Gegenprobe mit einem echten Bedrock-Aufruf ueber den geaenderten Pfad: Antwort,
Verbrauch und Kosten unveraendert, keine Stoerung protokolliert.

Neu sind 23 Pruefungen, insgesamt laufen 179 ohne Netzzugriff und ohne Kosten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -98,7 +98,7 @@ src/:
     entity_extractor.py: "Netzwerkanalyse (Sonnet). ACHTUNG: aktuell ohne Aufrufer in der App, nur regenerate_relations.py im Repo-Root nutzt es"
     translator.py: "Haiku-Uebersetzung in Batches a 5 (groessere Batches rissen den JSON-Output ab)"
     claude_client.py: "Shared Claude CLI Client, Usage-Tracking (Token, Kosten), Rate-Limit-Erkennung, Cancel via ContextVar. Routet je nach _ai_backend_var werkzeuglose Aufrufe zu bedrock_client"
-    bedrock_client.py: "EU-Modellweg ueber AWS Bedrock Converse (nur eu.-Inferenzprofile, Token-zu-USD-Umrechnung ueber BEDROCK_PRICING, gleiche Fehlerkategorien wie das CLI). EU-Umbau Phase 1"
+    bedrock_client.py: "EU-Modellweg ueber AWS Bedrock Converse (nur eu.-Inferenzprofile, Token-zu-USD-Umrechnung ueber BEDROCK_PRICING, gleiche Fehlerkategorien wie das CLI). EU-Umbau Phase 1. Wiederholt Kapazitaets- (503) und Kontingentfehler (429) nach BEDROCK_RETRY_WAITS (5/15/30s), begrenzt durch das Zeitbudget des Aufrufs und BEDROCK_RETRY_BUDGET_S je Refresh; Stoerungen landen im Refresh-Protokoll (refresh_log.error_message) und waehrend der Wartezeit als status_update in der Oberflaeche"
     eu_researcher.py: "EU-Recherche-Schleife (Phase 2): Bedrock-Modell schlaegt Suchanfragen vor, Code fragt staan, Modell entscheidet weiter/fertig. Bildet die 4-Phasen-Tiefenrecherche nach, liefert denselben JSON-Array-Text wie die CLI-WebSearch (Einstieg in researcher.search), akzeptiert NUR URLs aus echten staan-Treffern"
 
   feeds/:
@@ -165,6 +165,7 @@ tests/:
   test_qc_und_runden.py: "Absicherung der Duplikatpruefung und Abbruch der Suchrunden bei erreichter Treffergrenze"
   test_mehrfachantwort.py: "Antworten, in denen sich das Modell selbst korrigiert und mehrere Fassungen liefert, die ausfuehrlichste muss gewinnen"
   test_faktencheck_belegtiefe.py: "Belegzaehlung nach Medienhaus, Nachbedingung fuer bestaetigte Fakten, Sperre gegen das Hochstufen von developing, getrennte Bezeichnungen fuer Widerspruch und Widerlegung"
+  test_bedrock_wiederholung.py: "Wiederholung des EU-Wegs bei Kapazitaets- und Kontingentfehlern, Staffelung, Zeit- und Wartebudget, Sichtbarkeit im Refresh-Protokoll"
   test_quellenausgabe.py: "Ausgabetreue des Quellenverzeichnisses: Nummern aus dem Lagebild statt Zeilennummern, keine Kappung, ein Verlag ein Name, Statistik deckungsgleich mit dem Verzeichnis"
 ```