Gewinn-Close & Notfall-Stop nicht mehr beim Öffnen setzen

sr_close_min_gain_pct und auto_emergency_margin_pct auf 0 (User-Vorgabe): beim
Eröffnen einer Position wird nichts mehr automatisch armiert, nur manuell im UI
gesetzte Werte greifen. Mechanik bleibt im Code (reaktivierbar via ini).

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

CLAUDE.md

@@ -593,16 +593,17 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
     `set_sr_close_min_gain` · Snapshot `sr_close_min_gain`): unter der EUR-Schwelle
     wird am Level NICHT geschlossen. ⚠ Gemessen ist OHNE besser (Verworfen-Eintrag) —
     Opt-in auf User-Wunsch, UI-Status warnt. **Automatisch auf X % des Einsatzes
-    (User-Vorgabe 2026-07-23, `[trading] sr_close_min_gain_pct=3.0`, 1%→3% am selben
-    Tag nachgezogen zusammen mit dem margin-%-Notfall-Stop, s. u.):** bei JEDER
-    echt neuen Position (nicht beim Wiedererkennen nach Neustart) wird `sr_close_
-    min_gain` frisch auf `pct% × Margin dieser Position` gesetzt (`_check_auto_close`,
-    Margin kommt aus `trader.refresh()` unmittelbar davor im selben `_pos_loop`-Tick) —
-    überschreibt den manuell gemerkten Wert, persistiert via `_save_runtime_state`.
-    0 = aus (dann bleibt der manuell gesetzte/gemerkte Wert maßgeblich wie vorher).
-    ⚠ Gleiche Kopplungs-Regel wie beim festen Mindestgewinn: skaliert nur die Größe
-    desselben bereits gemessen-suboptimalen Mechanismus, kein neuer Risikotyp. Log
-    „Auto-Close armiert …" (getrennt) + „Gewinn-Close armiert … +X (3% Margin Y)".
+    (`[trading] sr_close_min_gain_pct`) — Stand 2026-07-24 AUF 0 = AUS (User-Vorgabe
+    „gewinn close … nicht setzen beim Eröffnen"; war kurz 1,0→3,0 am 2026-07-23).**
+    Bei `pct>0` wird bei JEDER echt neuen Position (nicht beim Wiedererkennen nach
+    Neustart) `sr_close_min_gain` frisch auf `pct% × Margin dieser Position` gesetzt
+    (`_check_auto_close`, Margin aus `trader.refresh()` im selben `_pos_loop`-Tick,
+    persistiert via `_save_runtime_state`, Log „Gewinn-Close armiert … +X (N% Margin
+    Y)"). Bei `pct=0` (aktuell) wird beim Öffnen NICHTS gesetzt — es bleibt der
+    manuell im UI gesetzte/gemerkte `sr_close_min_gain` (Default 0). ⚠ Beim Abschalten
+    2026-07-24 auch den persistierten Alt-Wert in `runtime_state.json` auf 0 gesetzt
+    (stand auf 17,17 vom letzten 3%-Auto-Set), sonst hätte ihn jeder neue Trade als
+    festen Mindestgewinn geerbt. Mechanik im Code erhalten (reaktivierbar via ini).
     **Gate verifiziert (2026-07-23, User-Nachfrage „darf nicht schließen bevor der
     Wert erreicht wurde"):** `_check_sr_close` prüft `pnl < sr_close_min_gain → return`
     **bevor** `_sr_close_hint`/`trader.close` überhaupt aufgerufen werden — isoliert
@@ -753,25 +754,22 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   Neustart wählt die Heuristik den TF binnen 1 min neu.
 - **Kein automatischer Tagesverlust-Schalter (Circuit Breaker):** vom User
   abgelehnt — NICHT einbauen. Bei 90 %-Margin-Sizing bleibt Drawdown-Risiko hoch.
-- **Notfall-Stop = AKTIV als margin-%-Modus (User-Vorgabe 2026-07-23,
-  `[trading] auto_emergency_margin_pct=3.0`).** Kurz-Historie: 2026-07-17 komplett
-  raus (2 % ≈ 0,76×ATR zerschoss die Squeeze-Trades, −48,94-€-Tag) · 2026-07-20
-  wenige Stunden als **3-%-GAP-NETZ (Balance-Basis)** zusammen mit `risk_pct=1.5` ·
-  mit der Rückkehr zu **Margin-Sizing 80 %** am selben Tag wieder aus (`auto_
-  emergency_pct=0`) · **2026-07-23 neu aktiviert, diesmal margin-basiert**
-  (`auto_emergency_margin_pct=3.0`, dritter Modus, s. u.), ausgelöst durch zwei
-  Notfall-Closes am selben Abend (−11,20 €/−20,47 €, s. „B0"-Analyse) — dabei hing
-  die Schwelle beim ersten Trade noch auf einem händisch aus dem UI-Feld getesteten
-  **Restwert von −5 €** (viel zu eng), nicht auf einer bewusst gesetzten Zahl. ⚠
-  **Kopplungs-Regel (gilt weiter, jetzt bewusst in Kauf genommen):** Ein %-Notfall-
-  Stop ist unter reinem Margin-Sizing (80 %, `risk_pct=0`) grundsätzlich enger als
-  der 2×ATR-SL — 3 % der Margin ist aber deutlich lockerer als der frühere 2 %-
-  Balance-Versuch (bei ~800 € Margin einer Standardposition sind 3 % ≈ 24 €, vs.
-  vorher 2 % von ~830 € Balance ≈ 16,62 €), soll als Sicherheitsnetz GEGEN genau
-  solche „vergessener enger Restwert"-Fälle wirken, nicht als enger Ersatz für den
-  Broker-SL. **Kein Backtest** (reines Risikomanagement-Sizing, kein Signal-Eingriff
-  — Track A, nicht Track B). Schutz-Stack jetzt: **Broker-SL 2×ATR + Trailing +
-  Time-Stop + margin-%-Notfall-Stop** als zusätzliches Netz.
+- **Notfall-Stop = AUS beim Öffnen (Stand 2026-07-24, `auto_emergency_margin_pct=0`,
+  `auto_emergency_pct=0`, `auto_emergency_loss=0`).** User-Vorgabe 2026-07-24: „gewinn
+  close und notfall close … nicht setzen beim Eröffnen" → alle drei Auto-Arm-Modi 0,
+  beim Öffnen einer Position wird KEIN Notfall-Stop gesetzt. Nur ein **manuell** im
+  UI-Feld eingegebener Wert armiert (bleibt bis zum nächsten Positionswechsel).
+  Kurz-Historie des margin-%-Modus: 2026-07-17 komplett raus (2 % ≈ 0,76×ATR zerschoss
+  die Squeeze-Trades, −48,94-€-Tag) · 2026-07-20 wenige Stunden als **3-%-GAP-NETZ
+  (Balance-Basis)** mit `risk_pct=1.5` · **2026-07-23 kurz margin-basiert `=3.0`**
+  (dritter Modus, ausgelöst durch zwei Notfall-Closes am selben Abend −11,20 €/−20,47 €,
+  wobei die Schwelle beim ersten Trade noch auf einem händischen UI-Restwert von −5 €
+  hing) · **2026-07-24 auf User-Wunsch wieder ganz AUS.** Der margin-%-Modus bleibt im
+  Code (retry-sicheres Armieren via `_emergency_margin_armed_ticket`, hat Vorrang vor
+  Balance-%/Fixwert wenn >0), reaktivierbar per ini. ⚠ Kopplungs-Regel (falls
+  reaktiviert): unter Margin-Sizing kann ein enger %-Stop schneller greifen als der
+  2×ATR-SL. Schutz-Stack aktuell: **Broker-SL 2×ATR + Trailing + Time-Stop** (der
+  Auto-Notfall-Stop ist inaktiv).
   **UI-Feld** (`#emg-input`, User-Vorgabe 2026-07-22, v=105) in der Trade-Leiste
   (rot, neben Gewinn-Close), Enter blurrt nur (kein Doppel-Send/ungewolltes 0,
   gleicher Fix wie Mindestgewinn 2026-07-22) — ein am Handy gesetzter Wert