analyze_scalping_costs.py: B3-Check fuer ein M1-Scalping-Modul

User-Frage "wie sinnvoll waere ein Scalping-Modul auf 1M-Basis". Vor dem Bau
gemessen, weil es zuerst eine Kosten- und keine Signalfrage ist: der Spread
ist absolut ~konstant und skaliert nicht mit der Zeitebene, die Bewegung schon.

Spread/ATR im Median: M1 0,319 · M5 0,193 · M15 0,133. Eine mittlere M1-Kerze
ist nur 3,4x so gross wie der Spread. Noetige Trefferquote bei 1:1 steigt von
50 auf 65,9 %; um 01:00 uebersteigt der Spread mit 1,051xATR_M1 die gesamte
durchschnittliche Bar-Spanne.

Dazu drei Gruende, die schwerer wiegen als die Kosten:
- M1-Historie ist hart bei 80.000 Bars / 80 Tage gedeckelt -> kein
  2-Stichproben-Test ueber verschiedene Regime moeglich
- das Aufloesungs-Artefakt vom 05.08. trifft M1 am haertesten (Scalp lebt in
  2-3 Bars, Bar-Sim ueberschaetzt enge Stops)
- der Slippage-Schwanz ist absolut: Ø 0,234 $ uebersteigt einen 2xATR_M1-Stop
  (0,174 $) bereits im Mittel

Empfehlung: kein eigenstaendiges Modul; messbar waere der Squeeze auf M1
(offene Variante B) beschraenkt auf 10-17 Uhr.

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

CLAUDE.md

@@ -284,6 +284,51 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   ~15 s→5 s schneller erkannt, dann ~1 s Handeln (`_pos_loop`). Gleiche validierte M5-Regel,
   reine Infra (kein Backtest nötig). **Variante B (Squeeze auf M1) = OFFEN/UNBELEGT** — erst
   backtesten, wenn der M1-Logger (`candles_m1`, seit 2026-07-21) ab ~2027-01 genug History hat.
+- **⚠⚠ SCALPING-MODUL AUF M1 = ABGERATEN, bevor überhaupt gebaut wird (gemessen
+  `analyze_scalping_costs.py`, 2026-08-06, User-Frage „wie sinnvoll wäre ein
+  zusätzliches Modul Scalping auf 1M-Basis, über das Dashboard steuerbar?").**
+  Es ist zuerst eine **Kosten-**, keine Signalfrage: der Spread ist bei WTI absolut
+  ~konstant und skaliert NICHT mit der Zeitebene, die Bewegung schon.
+  | TF | Ø ATR | Ø Spread | **Median Sp/ATR** | Ø Sp/ATR |
+  |---|---|---|---|---|
+  | **M1** | 0,0870 $ | 0,0254 $ | **0,319** | **0,416** |
+  | M5 | 0,1677 $ | 0,0226 $ | 0,193 | 0,256 |
+  | M15 | 0,2269 $ | 0,0250 $ | 0,133 | 0,171 |
+  Der Spread ist auf allen drei Ebenen praktisch derselbe Betrag — **eine mittlere
+  M1-Kerze ist nur 3,4× so groß wie der Spread.** Nötige Trefferquote bei 1:1
+  (Ziel/Stop je 1×ATR_M1): **65,9 %** statt 50 %; bei 0,5:0,5 sogar **81,9 %**.
+  Zum Vergleich: nichts in diesem Projekt hat je über ~46 % geliefert.
+  ⚠ **Nachts ist es arithmetisch unmöglich:** um **01:00 beträgt der Spread
+  1,051×ATR_M1** — er ist größer als die durchschnittliche Bar-Spanne (00:00 0,801 ·
+  06:00 0,750). Handelbar wäre allenfalls **10–17 Uhr** (0,210–0,265), also dort, wo
+  M1 ungefähr die heutigen M5-Kosten erreicht.
+  ⚠⚠ **DREI Gründe, die schwerer wiegen als die Kosten selbst:**
+  **(1) Ein Backtest nach Projektstandard ist NICHT möglich.** Die M1-Historie des
+  Brokers ist hart bei **80.000 Bars = 80 Tage** gedeckelt (`copy_rates_from_pos`
+  liefert darüber `None`, `copy_rates_range` ebenso). Zwei Stichproben à 40 Tage
+  liegen im **selben Regime** — genau die Konstellation, an der ORB und die
+  Dead-Hour-Stunde 13 gescheitert sind. Der eigene `candles_m1`-Logger steht bei
+  19 Tagen und erreicht die 180 erst ~2027-01.
+  **(2) Das Auflösungs-Artefakt trifft M1 am härtesten.** `analyze_trail_resolution.py`
+  (05.08.) hat gezeigt: eine Bar-Simulation **überschätzt enge Stops systematisch**,
+  Kipp-Punkt bei ~0,3×ATR. Ein Scalp lebt in 2–3 Bars — eine M1-Bar-Sim hat dort
+  praktisch keine Auflösung mehr. Ein positives Ergebnis wäre nicht überprüfbar; es
+  bräuchte Tick-Daten.
+  **(3) Der Slippage-Schwanz ist ABSOLUT und frisst deshalb den kleinen Stop.**
+  Gemessen (`analyze_execution.py`): Median 0,017 $ (unkritisch), **Ø 0,234 $, Max
+  4,192 $**. Ein 2×ATR_M1-Stop ist **0,174 $** breit — der MITTLERE Slippage-Wert
+  übersteigt ihn bereits. Der reale 0,751-$-Fall vom 30.06. entspricht **8,6×** einem
+  M1-Stop gegen 2,2× einem M5-Stop; er löscht rund **11** gewonnene Scalps statt 4.
+  ✅ **Was FÜR die Idee spricht (fairerweise):** der Bau wäre billig — Pending-Stop-
+  Orders, `_auto_guard`, `_pending_ziel` mit Vorrang, Dashboard-Toggle (Muster
+  🚀 BRK / 🎯 SIG), `runtime_state.json`, B4-Monitor und die Setup-Kennzeichnung
+  (seit 06.08.) existieren alle. Und **höhere Frequenz = schnellere Validierung**:
+  der Squeeze braucht 20 Trades und hat nach 5 Tagen 8.
+  ✅ **Empfehlung: KEIN eigenständiges Scalping-Modul, aber eine engere Variante ist
+  messbar** — der **Squeeze auf M1** (= die schon offene Variante B), beschränkt auf
+  10–17 Uhr, mit ruhender Stop-Order. Das ist kein neues Signal, sondern eine
+  validierte Regel auf einer feineren Ebene; die 80 Tage reichen für ein
+  **Ausschluss**-Urteil (nicht für eine Bestätigung).
   Snapshot **`wave.squeeze {state, dir, level, box_atr}`**: `active` = Ausbruch (echtes
   Signal LONG/SHORT) · `armed` = komprimiert, Ausbruch steht bevor · None = keine
   Kompression (transient — der Ausbruch weitet die Box, Signal klärt sich selbst).