G/V-Trennung geprueft: Adoptions-Sperre riss bei JEDEM Neustart auf

User: "ueberpruefe ob wirklich die G/V und G/V BRK Anzeigen stimmen, besonders
bei gleichzeitig laufenden Trades. Die Anzeige darf jeweils nur den eigenen
Slot anzeigen."

FRONTEND SAUBER: #hdr-pnl liest nur d.position, #hdr-pnl-brk nur
d.position_brk - keine Summe, kein Fallback. Aber das ist die falsche Stelle
zum Suchen: stehen im Backend beide Felder auf derselben Position, kann keine
Anzeige das mehr richten. Geprueft wurde deshalb die AUSWAHL in
TradeManager._refresh_locked.

⚠⚠ FUND 1 - die Sperrliste kannte nur zwei von DREI Quellen eines BRK-Tickets:
  trader_brk.ticket   ✅  nur im Speicher
  _pending_tickets    ✅  nur im Speicher
  _brk_restore        ❌  FEHLTE - und nur das ueberlebt den Neustart
Nach einem Neustart sind die ersten beiden leer, und die Reihenfolge im
_pos_loop besiegelt es: trader.refresh() laeuft DREI Zeilen vor _rebind_brk().
Slot 1 greift die BRK-Position also, bevor sie zurueckgebunden werden kann.
_rebind_brk erkennt das zwar und bricht ab - damit ist der Schaden aber nur
festgestellt, nicht behoben: die BRK-Position haengt am falschen Slot, ihr G/V
steht links statt rechts, und "G/V BRK" zeigt "—". Danach sieht alles normal
aus, was es besonders schwer sichtbar macht.
Behoben ueber getattr(..., None), also unabhaengig davon, WANN das Attribut
gesetzt wird - genau die Reihenfolge-Falle, die in zwei Tagen zweimal
zugeschlagen hat.

✅✅ FUND 2 - zwei verschiedene Rechnungen nebeneinander. Bei geschlossenem
Markt zeigt Slot 1 seit dem 01.08. eine HL-Schaetzung (pnl_hl), der BRK-Slot
bekam die nie und zeigte den EINGEFRORENEN Broker-Wert, ohne dass man es der
Anzeige ansieht. Neu pnl_hl_brk, mit ≈ markiert. Geprueft statt angenommen,
dass _tick_size/_tick_value am BRK-Slot gesetzt sind.

✅ day_pl.open summiert korrekt BEIDE Slots - die Summe gehoert dorthin, die
Trennung in die beiden G/V-Felder.

BELEG - tests/test_slot_gv.py, 6 Tests auf dem ECHTEN TradeManager (Broker
gestubbt): zwei Positionen gleichzeitig je im eigenen Slot · Slot 1 adoptiert
die BRK-Position nicht · Pending-Fill wird nicht weggeschnappt · der BRK-Slot
adoptiert nie · plus die Regressionsprobe, die den alten Zustand festhaelt.
NEUE PIPELINE-STUFE E (tools/check_slots.py): die Sperrliste muss alle drei
Namen erwaehnen. Mutationsprobe: Merker entfernt -> Exit 1.
⚠⚠ Ehrlich zur Arbeitsteilung: der pytest belegt den MECHANISMUS, baut die
Lambda aber selbst nach und bleibt bei der Mutation gruen. Erst die statische
Stufe belegt, dass die ENGINE sie richtig verdrahtet. Keine der beiden allein
haette gereicht.

⚠⚠ NEBENBEFUND, korrigiert: mein Schreib-Helfer hat SECHS Dateien still von
LF auf CRLF gedreht (io.open(...,"w") uebersetzt auf Windows). Mein erster
Check mit `grep -c $'\r$'` meldete faelschlich 0 - erst die BYTE-Zaehlung zeigte
8959 CR in CLAUDE.md. Alle sechs auf LF zurueckgesetzt. core.autocrlf=true
haette es im Repo normalisiert, im Arbeitsbaum aber nicht.

Live verifiziert: Slot 1 T=50396824 (+10,34), BRK flat, day_pl.open 10,34 -
kein gemeinsames Ticket. Deploy mit --feld pnl_hl_brk, alle 5 Schritte gruen.
⚠ Noch nicht beobachtet: ein Neustart MIT offener BRK-Position - der Fall, den
der Fix adressiert.

v=201.

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

web/app.js

@@ -1138,12 +1138,19 @@ function render(d) {
   const bpEl2 = $("hdr-pnl-brk"), bpos = d.position_brk;
   if (bpos && bpos.ticket) {
     const whtB = d.wht_pct || 0;
-    const rawB = Number(bpos.pnl) || 0;
+    // ⚠⚠ Bei geschlossenem Markt DIESELBE Rechnung wie links: der
+    //   Broker-P&L steht dann still. Ohne `pnl_hl_brk` zeigte links eine
+    //   HL-Schätzung und rechts der eingefrorene Broker-Wert — zwei
+    //   verschiedene Rechnungen nebeneinander, ohne sichtbaren Unterschied.
+    const useHlB = d.market_closed && d.pnl_hl_brk != null;
+    const rawB = useHlB ? d.pnl_hl_brk : (Number(bpos.pnl) || 0);
     const netB = rawB > 0 ? rawB * (1 - whtB / 100) : rawB;
-    bpEl2.textContent = (netB >= 0 ? "+" : "") + cs + fmt(netB, 2);
+    bpEl2.textContent = (useHlB ? "≈" : "") + (netB >= 0 ? "+" : "") + cs + fmt(netB, 2);
     bpEl2.className = netB > 0 ? "up" : netB < 0 ? "down" : "";
     bpEl2.title = `Breakout-Autotrader, Ticket ${bpos.ticket} · ${bpos.lots} Lots @ `
-      + `${bpos.entry} · Trailing ${bpos.trail ? "an" : "AUS"}`;
+      + `${bpos.entry} · Trailing ${bpos.trail ? "an" : "AUS"}`
+      + (useHlB ? `· Schätzung auf Basis des Hyperliquid-Kurses `
+                  + `(Broker-P&L ${fmt(bpos.pnl || 0, 2)} ${cs} eingefroren).` : "");
   } else {
     bpEl2.textContent = "—";
     bpEl2.className = "";
@@ -2367,7 +2374,7 @@ async function closeSlot(slot, label, pnl) {
 //   und der Browser zeigte Altes. Statt das jedes Mal von Hand zu diagnostizieren,
 //   sagt die Seite es jetzt selbst.
 // ⚠ Bewusst SICHTBAR statt nur Konsole: die Konsole sieht am Handy niemand.
-const _JS_V = "200";
+const _JS_V = "201";
 {
   const htmlV = document.body && document.body.dataset
     ? document.body.dataset.htmlV : null;

web/index.html

@@ -12,9 +12,9 @@
        ⚠ LOKAL eingebunden, kein CDN: die PWA laeuft ueber WireGuard
        und muss offline funktionieren. -->
   <link rel="stylesheet" href="pico.min.css?v=1">
-  <link rel="stylesheet" href="style.css?v=200">
+  <link rel="stylesheet" href="style.css?v=201">
 </head>
-<body data-html-v="200">
+<body data-html-v="201">
   <!-- Modul-Menü (ganz oben) -->
   <nav id="tabs">
     <button class="tab active" data-view="dash">Dashboard</button>
@@ -421,6 +421,6 @@
   </div>
   <div id="toast" class="toast hidden"></div>
 
-  <script src="app.js?v=200"></script>
+  <script src="app.js?v=201"></script>
 </body>
 </html>