breakout_k mit vollem Live-Gate-Stack gemessen

Nachgeholt, was in der Vollpruefung offen blieb: die ungegatete Messung zeigte
k=0,5/0,8/1,0 besser als den Live-Wert 0,3 - aber ohne min_conf, HTF-Filter und
Entry-Raum. backtest_breakout_gated.py schliesst die Luecke mit den ECHTEN
Methoden (_build, _confirm_breakout-Mechanik, _room_gate mit kausalen M5-Pivots).

  k=0,0  H1 -0,173/-193   H2 +0,003/  +7
  k=0,2  H1 -0,185/-149   H2 -0,012/ -16
  k=0,3  H1 -0,160/-122   H2 -0,036/ -47   (LIVE)
  k=0,5  H1 -0,127/ -85   H2 -0,041/ -47
  k=0,8  H1 -0,101/ -54   H2 -0,012/ -11
  k=1,0  H1 -0,096/ -45   H2 -0,016/ -12

Bestaetigt: k=0,5/0,8/1,0 schlagen 0,3 in BEIDEN Haelften, die Nachbarn halten
mit, und die OR verbessert sich in H1 monoton - also nicht nur
Handelsvermeidung. Die vorab fixierte Regel ist erfuellt.

TROTZDEM keine Umstellung empfohlen, und der Grund ist kein Messfehler sondern
eine Zweckfrage: alle Werte bleiben negativ (PF 0,70-1,01), das Gate begrenzt
Schaden statt Edge zu erzeugen; der Auto-Signal-Pfad ist ohnehin aus, das Signal
ist ein Vorschlag fuer den Menschen, und dessen gemessener Vorteil entstand auf
der k=0,3-Population; k=0,8 kuerzt die Empfehlungen um ~39 % und treibt den
WARTEN-Anteil weiter hoch, der mit 93 % ohnehin im Fokus steht.

Zwei benannte Abweichungen der Simulation:
- _confirm_breakout misst seinen Timeout mit time.time() gegen 3600 s. Im
  Bar-Loop vergeht keine Wall-Clock-Zeit, der Timeout wuerde nie feuern. 3600 s
  sind auf M5 exakt 12 Bars, so wird gezaehlt. Merke: jede time.time()-Messung
  im Live-Code ist in einer Bar-Simulation stumm.
- hour=None, weil die EIA-Pruefung in _build ueber datetime.now(_BERLIN) laeuft -
  mit Bar-Stunde wuerde ein Lauf am Mittwoch 15:30-16:30 alle Bars blocken.

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

.gitignore

@@ -55,3 +55,5 @@ desktop.ini
 run_all.log
 run_all.err
 rerun_rejected.*
+gated.log
+gated.err