Deployment-Drift: Stufe 1 (Trail-mult) + Stufe 2 (Entscheidungs-Telemetrie)

Behebt die strukturelle Schwachstelle, die heute dreimal zugeschlagen hat:
Komponenten werden unter anderen Bedingungen BETRIEBEN als VALIDIERT.
Track B schuetzt gegen Overfitting, nicht gegen Deployment-Drift.

STUFE 1 (core/trailing.py): _MULT_BY_TF durchgehend 1,5 (vorher M15 2,0 /
M30 2,5 / H1 3,0) und _MULT_BREAKOUT_ADD 0,5 -> 0,0. Die Staffelung war nie
gemessen; backtest_trailing.py validiert nur 1,5 und die breiteren Werte
sind dort messbar schlechter (80k Bars, 2 Halbjahre):
    mult 1,5  H1 SigmaR  -249 · H2 +1252 · Worst -1,50
    mult 2,0  H1 SigmaR  -412 · H2 +1187 · Worst -2,00
    mult 2,5  H1 SigmaR -1367 · H2 +1450 · Worst -2,50
Auf M30 fuhr der Bot also 5,5x schlechteres H1 und einen 67 % groesseren
Einzelverlust; bei Breakouts waren es 3,0 - nie getestet. Relevant, weil die
TF-Heuristik oft auf M15/M30 landet (31.07.: 19 von 33 Phasen).

STUFE 2a (wave_rec/history/engine): jede Empfehlung loggt einen
maschinenlesbaren block_reason - deadband, dead_hour, eia, htf_counter,
stretch, min_conf, breakout_pending, entry_room, no_data, stale. DB migriert
(Backup angelegt). Ohne den war nicht feststellbar, WELCHES der Gates die
93 % WARTEN erzeugt (Backtest-Erwartung ~43 %).

STUFE 2b (analyze_divergence.py, NEU): haelt vier Dinge gegen die
Backtest-Erwartung - A Signal-Verteilung, B Gate-Anteile inkl.
"im Backtest modelliert?", C TF-Wechsel-Rate, D0 Modell-Kalibrierung,
D Merkmals-Drift gegen _PB_MU/_SD.

LEHRE AUS DEM BAU SELBST: die Merkmals-Drift (D) haette den realen Fehler
NICHT gefangen - mom3 lag nur 0,50 Sigma unter mu, bei Gewicht 1,43 wurden
daraus aber -0,71 im Logit (23 % statt 41 % vorhergesagt). Deshalb ist D0
der schaerfere Test und die D-Schwelle auf 0,5 Sigma gesetzt.

Erster Lauf nach dem Fix bestaetigt das Nachtraining live:
D0 = 27,0 % vorhergesagt vs 28,0 % real (vorher 23 vs 41).

Stufe 3 (geteilter Exit-Kern) bleibt offen, spaeter und einzeln.

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

core/trailing.py

@@ -107,16 +107,31 @@ _TF_LABELS   = {
     mt5.TIMEFRAME_H1:  "H1",
 }
 
-# Trail-Multiplikator je Timeframe: niedrige TF (Scalp) → enger Stop,
-# hohe TF (Trend) → mehr Puffer. Ersetzt die alte 2.5–4.5-Logik.
+# Trail-Multiplikator je Timeframe.
+# ⚠⚠ ANGEGLICHEN AUF DEN GEMESSENEN WERT 1,5 (2026-07-31, Stufe 1 der
+# Deployment-Drift-Behebung). VORHER: M15 2,0 · M30 2,5 · H1 3,0 (+0,5 bei
+# Breakouts) — diese Staffelung war **nie gemessen**. `backtest_trailing.py`
+# validiert ausschließlich 1,5, und die breiteren Werte sind dort MESSBAR
+# SCHLECHTER (80k Bars, 2 Halbjahre, Signal Trend+Reversal):
+#     mult 1,5 (start 0,3):  H1 ΣR  −249  · H2 +1252 · Worst −1,50
+#     mult 2,0 (start 0,3):  H1 ΣR  −412  · H2 +1187 · Worst −2,00
+#     mult 2,5 (start 0,3):  H1 ΣR −1367  · H2 +1450 · Worst −2,50
+# Auf M30 fuhr der Bot also 5,5× schlechteres H1 und einen 67 % größeren
+# Einzelverlust; mit `_MULT_BREAKOUT_ADD` waren es bei Breakouts sogar 3,0 —
+# ein Wert, den nie jemand getestet hat. Real relevant, weil die TF-Heuristik
+# häufig auf M15/M30 landet (31.07.: 19 von 33 Phasen).
+# ⚠ Falls die Staffelung je zurück soll: erst `backtest_trailing.py` auf
+# M15-/M30-BASIS-Signalen laufen lassen — bisher misst er nur M5.
 _MULT_BY_TF = {
     mt5.TIMEFRAME_M1:  1.5,
     mt5.TIMEFRAME_M5:  1.5,
-    mt5.TIMEFRAME_M15: 2.0,
-    mt5.TIMEFRAME_M30: 2.5,
-    mt5.TIMEFRAME_H1:  3.0,
+    mt5.TIMEFRAME_M15: 1.5,
+    mt5.TIMEFRAME_M30: 1.5,
+    mt5.TIMEFRAME_H1:  1.5,
 }
-_MULT_BREAKOUT_ADD = 0.5   # Breakouts brauchen etwas mehr Luft (gedeckelt)
+# 0,0 statt 0,5: der Aufschlag hob Breakout-Trades auf mind. 2,0 — gemessen
+# schlechter als 1,5 (s. o.) und für Breakouts nie separat validiert.
+_MULT_BREAKOUT_ADD = 0.0
 
 _PHASE_RANK = {"Init": 0, "Trail": 1, "Lock": 2}