Ruhende Orders: aufraeumen statt liegenlassen (User-Vorgabe)

User: "was sind ruhende orders. Loesche die wenn der trade nicht eroeffnet
werden kann." Anlass: MT5 zeichnete SL/TP-Linien, obwohl keine Position lief.
Das waren die liegenden Stop-Orders des Breakout-Traders - MT5 stellt jede
Pending-Order samt mitgeschicktem SL selbst dar. Der Bot exportiert NIE SL/TP
ins Chart (0 Treffer im .mq5, keine SL-Zeile in der CSV). Kein Anzeigefehler.

ZWEI ECHTE VERWAISUNGS-PFADE GEFUNDEN. _manage_squeeze_pending stieg VOR dem
Aufraeum-Block aus, wenn squeeze_pending_entry=false oder kein Symbol da war.
Die Orders sind ORDER_TIME_GTC - sie verfallen NICHT. Eine so verwaiste Order
haengt beim Broker, wird von niemandem mehr bewertet und kann Stunden spaeter
fuellen: ohne Dedup, ohne Guard-Pruefung und (bis heute) ohne Trailing.
Neu engine._pendings_abraeumen(sym, grund) - beide Pfade raeumen jetzt ab.

DIE EIGENTLICHE VORGABE: ein halbes Setup wird aufgeloest. Scheitert eine Seite
mit Lot-Fehler (freie Margin reicht nicht fuers Mindestlot), wird auch die
Gegenseite storniert - der gemessene Squeeze ist ein Ausbruch in BEIDE
Richtungen; laege nur eine Seite, handelte der Bot ihn nur noch in eine.
Ausdruecklich NICHT bei "Kurs hat das Level bereits passiert": das ist
voruebergehend und betrifft nur die eine Seite. Der Lot-Fehler betrifft das
KONTO und damit beide.
Erkannt ueber die Konstante mt5_utils.LOT_ZU_KLEIN, nicht ueber ein deutsches
Wort im Fliesstext - eine Erkennung, die an einer Formulierung haengt, hoert
still auf zu funktionieren und faellt dabei auf die stille Seite.

⚠⚠ DIE LOG-DROSSEL WAR AM SELBEN TAG ZUM ZWEITEN MAL AUSGEHEBELT - durch meine
eigene Verbesserung. Vormittags lag der Merker in EINER Variable fuer beide
Seiten (behoben). Dann bekam die Meldung ueber lot_grund ihre Zahlen, und die
freie Margin aendert sich mit jedem Tick: der Text war jedes Mal neu, der
Vergleich traf immer zu, wieder 2 Zeilen pro Sekunde.
Gedrosselt wird jetzt auf die URSACHE, nicht auf ihre Formulierung (_err_key:
alle Zahlen -> #). Gemessen: 7 Zeilen in 90 s statt ~180, und die verbliebenen
sind echte Wechsel zwischen den beiden Ursachen.
Lehre: eine Drossel, die einen TEXT vergleicht, ist so stabil wie der Text.

Live verifiziert: 0 liegende Orders, keine verwaisten Reste, Startup-Schonfrist
raeumt korrekt ab, Orders kommen danach zurueck sobald die Margin reicht.
Pipeline gruen (A-G), 97 Tests, deployt mit --feld squeeze_block.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -9342,6 +9342,57 @@ mit Begründung im Code, damit es nicht als Versehen gelesen wird.
 **Pipeline jetzt: A · A2 · A3 · B · B2 · C · C2 · D · E · F · G** — alle grün,
 97 Tests, deployt und verifiziert.
 
+## ⚠⚠ RUHENDE ORDERS: AUFRÄUMEN STATT LIEGENLASSEN (User-Vorgabe 2026-08-20)
+
+User: *„was sind ruhende Orders. Lösche die, wenn der Trade nicht eröffnet
+werden kann."* — Anlass war, dass MT5 SL/TP-Linien zeichnete, obwohl keine
+Position lief. **Das waren die liegenden Stop-Orders des Breakout-Traders**;
+MT5 stellt jede Pending-Order samt ihrem mitgeschickten SL selbst dar. ✅ Der
+Bot exportiert **nie** SL/TP ins Chart (0 Treffer im `.mq5`, keine `SL;`-Zeile
+in der CSV) — kein Anzeigefehler, sondern eine Broker-Funktion.
+
+⚠⚠ **DIE PRÜFUNG DER FRAGE FÖRDERTE ZWEI ECHTE VERWAISUNGS-PFADE ZUTAGE.**
+`_manage_squeeze_pending` stieg **VOR** dem Aufräum-Block aus, wenn
+`squeeze_pending_entry=false` **oder** kein Symbol da war (MT5-Aussetzer). Die
+Orders sind `ORDER_TIME_GTC` — **sie verfallen nicht**. Eine so verwaiste Order
+hängt beim Broker, wird von niemandem mehr bewertet und kann Stunden später
+füllen: **ohne Dedup, ohne Guard-Prüfung** und (bis zum Fix vom selben Tag)
+**ohne Trailing**.
+✅ Neu `engine._pendings_abraeumen(sym, grund)` — beide Pfade räumen jetzt ab,
+statt nur zurückzukehren.
+
+✅ **UND DIE EIGENTLICHE VORGABE UMGESETZT: ein halbes Setup wird aufgelöst.**
+Scheitert eine Seite mit **Lot-Fehler** (die freie Margin reicht nicht einmal
+fürs Mindestlot), wird auch die **Gegenseite** storniert. Grund: der gemessene
+Squeeze ist ein Ausbruch aus der Box in **beide** Richtungen; läge nur eine
+Seite, handelte der Bot ihn nur noch in **eine** — das ist nicht das Setup, das
+validiert wurde.
+⚠ **Ausdrücklich NICHT bei „Kurs hat das Level bereits passiert"**: das ist
+vorübergehend und betrifft naturgemäß nur die eine Seite (der Kurs steht gerade
+an der Box-Kante); die Gegenseite bleibt ein gültiger Einstieg. Der Lot-Fehler
+dagegen betrifft das **Konto** und damit beide Seiten.
+⚠ Erkannt über die **Konstante `mt5_utils.LOT_ZU_KLEIN`**, nicht über ein
+deutsches Wort im Fließtext: eine Erkennung, die an einer Formulierung hängt,
+hört still auf zu funktionieren, sobald jemand den Satz umschreibt — und fällt
+dabei auf die **stille** Seite (kein Aufräumen), nicht auf die laute.
+
+⚠⚠⚠ **DIE LOG-DROSSEL WAR AM SELBEN TAG ZUM ZWEITEN MAL AUSGEHEBELT — durch
+meine eigene Verbesserung.** Vormittags lag der Merker in EINER Variable für
+beide Order-Seiten (behoben). Dann bekam die Meldung über `lot_grund` ihre
+Zahlen — und die **freie Margin ändert sich mit jedem Tick**. Der Text war also
+jedes Mal neu, der Vergleich `!= err` traf immer zu: wieder **2 Zeilen pro
+Sekunde**.
+✅ Gedrosselt wird jetzt auf die **URSACHE**, nicht auf ihre Formulierung
+(`_err_key`: alle Zahlen → `#`). Gemessen: **7 Zeilen in 90 s** statt ~180 —
+und die verbliebenen sind echte Wechsel zwischen den beiden Ursachen, kein Lärm.
+⚠ **Lehre: eine Drossel, die einen TEXT vergleicht, ist so stabil wie der Text.**
+Sobald eine Meldung Messwerte enthält, muss auf einen normalisierten Schlüssel
+gedrosselt werden.
+
+✅ Live verifiziert nach dem Deploy: **0 liegende Orders**, keine verwaisten
+Reste, Startup-Schonfrist räumt korrekt ab und die Orders kommen danach zurück,
+sobald die Margin reicht.
+
 ## ⚠⚠⚠ P(break) IST LIVE **INVERTIERT** — und es steuert echtes Geld (2026-08-19)
 
 Die fällige Messung ist entscheidbar geworden: **n=530 entkoppelt** gegen die