G/V-Lag: 1-s-Fallback + ehrlicher Verbindungspunkt (v=151)

Zuerst gemessen, dann gedreht - und das Backend war NICHT das Problem:
  /api/snapshot   75 Abrufe in 20 s -> 21 verschiedene ts = ~1/s
  WebSocket-Push  direkt am Socket gemessen: Median 1,04 s (min 1,00 max 1,06)
  G/V-Aenderungen Ø 1,44 s - das ist der Markt, keine Verzoegerung

Die ganze Server-Kette liefert bereits 1 s. Der Lag entsteht erst am Handy:
bricht der WebSocket STILL weg (WireGuard-Aussetzer, App-Wechsel), traegt nur
noch der REST-Poll - und der stand auf 4 s.

POLL_MS 4000 -> 1000, aber mit Sperre: solange der WS liefert (lastWsMs,
Fenster WS_FRISCH_MS=2200 ms), ueberspringt der Poll den Abruf. Kein
zusaetzlicher Verkehr im Normalfall.

Denkfehler, den erst die Simulation zeigte: der erste Entwurf las die
WS-Frische aus lastRecvMs (jede Quelle) - damit drosselte sich der Poll SELBST
und kam bei totem WS nur auf 2,9 s statt 1 s. Jetzt zwei getrennte Uhren.

Simuliert: WS gesund -> 0 Zusatz-Abrufe, max. Alter 0,9 s. WS tot -> 1/s, max.
Alter 0,9 s. WS traege (5 s) -> max. 2,9 s. Vorher bei totem WS: 4,0 s.

Der Verbindungspunkt log: er wurde nur bei sock.onclose auf "off" gesetzt, aber
genau der Fall, der den Lag erzeugt, feuert KEIN onclose - der Socket haengt
still, der Punkt blieb gruen. Neu .dot.stale (bernstein, pulsierend) ab 3,5 s
ohne frischen Snapshot: gemessen wird, was ANKOMMT, nicht was der Socket ueber
sich behauptet.

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

CLAUDE.md

@@ -260,6 +260,37 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   ⚠ Die 40 vorhandenen `if (!el) return;`-Wächter feuern jetzt nicht mehr. Sie
   bleiben stehen (kein Nutzen im Entfernen, und sie greifen weiter, wenn jemand
   `$streng` benutzt) — beim Lesen aber mitdenken.
+- **✅ G/V-LAG: 1-s-FALLBACK + EHRLICHER VERBINDUNGSPUNKT (2026-08-07, v=151).**
+  User: „G/V wird extrem lagged — 1 Sekunde".
+  ⚠⚠ **ZUERST GEMESSEN, DANN GEDREHT — und das Backend war NICHT das Problem:**
+  | Stufe | gemessen |
+  |---|---|
+  | `/api/snapshot` (75 Abrufe / 20 s) | **21 verschiedene `ts`** = ~1/s |
+  | **WebSocket-Push, direkt am Socket** | **Median 1,04 s** (min 1,00 · max 1,06) |
+  | G/V-Änderungen | Ø 1,44 s — das ist der **Markt**, keine Verzögerung |
+  **Die ganze Server-Kette liefert bereits 1 s.** Der Lag entsteht erst am Handy:
+  bricht der WebSocket **still** weg (WireGuard-Aussetzer, App-Wechsel), trägt nur
+  noch der REST-Poll — und der stand auf **4 s**.
+  ✅ **`POLL_MS` 4000 → 1000, aber MIT Sperre:** solange der WS liefert
+  (`lastWsMs`, Fenster `WS_FRISCH_MS`=2200 ms), überspringt der Poll den Abruf.
+  **Kein zusätzlicher Verkehr im Normalfall** (~14 KB/Abruf über WireGuard).
+  ⚠ **Denkfehler, den erst die Simulation zeigte:** der erste Entwurf las die
+  WS-Frische aus `lastRecvMs` (jede Quelle) — damit **drosselte sich der Poll
+  selbst** und kam bei totem WS nur auf **2,9 s** statt 1 s. Jetzt zwei getrennte
+  Uhren: `lastWsMs` (nur `sock.onmessage`) entscheidet über das Überspringen,
+  `lastRecvMs` (jede Quelle) über die Stale-Anzeige.
+  **Simuliert:** WS gesund → **0** Zusatz-Abrufe, max. Alter **0,9 s** · WS tot →
+  1/s, max. Alter **0,9 s** · WS träge (5 s) → max. 2,9 s. Vorher bei totem WS:
+  4,0 s.
+  ✅ **Der Verbindungspunkt log** — behoben. Er wurde **nur** bei `sock.onclose`
+  auf „off" gesetzt; genau der Fall, der den Lag erzeugt, feuert aber **kein**
+  `onclose`: der Socket hängt still, der Punkt blieb **grün**. Neu `.dot.stale`
+  (bernstein, pulsierend) ab **3,5 s** ohne frischen Snapshot — gemessen wird,
+  was ANKOMMT, nicht was der Socket über sich behauptet. Tooltip nennt das Alter.
+  ⚠ Kein Konflikt mit `render()`, das `className` komplett überschreibt: läuft
+  `render()`, ist gerade ein Snapshot angekommen und `stale` gehört ohnehin weg.
+  `.dot.stale` steht in `style.css` **nach** `.on`/`.off` — gleiche Spezifität,
+  die Reihenfolge entscheidet.
 - **⚠ NEUE HTML-Elemente IMMER null-sicher ansprechen (Fix 2026-08-01).**
   `index.html` und `app.js` werden vom Browser **unabhängig** gecacht. Trifft neue JS
   auf eine alte, gecachte HTML, wirft ein direkter Zugriff (`$("neu").textContent = …`)
@@ -4151,7 +4182,7 @@ dort bereits nachvalidiert, ØR +0,305.) **Eine** Oberfläche:
   („⚠ die Welle (steuert die Order) schweigt").
   Live gegengerechnet, beide Zeilen erscheinen wie beabsichtigt.
   ⚠ Reine Anzeige — an Gewichten, Gates und Order-Logik ist nichts geändert.
-- Asset-Version aktuell **v=150** (in `web/index.html` hochzählen, siehe Workflows).
+- Asset-Version aktuell **v=151** (in `web/index.html` hochzählen, siehe Workflows).
   Schriftgrößen 2026-07-24 global **+4px** (2× je +2px auf User-Wunsch; Body-Basis
   14→18px). ⚠ Betrifft in `style.css` sowohl `font-size:Npx` (71×) ALS AUCH die
   `font:<weight> Npx/…`-**Shorthand** (3×: `.ms-chip`/`.ms-bos-lbl`/`.sqm-badge` —