Schrift skaliert mit dem Fenster: 96 px-Werte -> rem + fluide Wurzel (v=167)

User-Wunsch: "Schriftarten im Dashboard auf em einstellen, damit auf jedem
Geraet oder je nach Fenstergroesse die Schriftgroesse automatisch angepasst
wird."

Umgesetzt mit rem + fluider Wurzel, NICHT mit em. Der Wunsch war richtig,
die genannte Einheit nicht: `em` ist relativ zum ELTERNelement und reagiert
auf die Fenstergroesse gar nicht -- verschachtelt multipliziert es sich sogar
(h2 mit 1,2em in einer Karte mit 1,1em landet bei 1,32x).

  html { font-size: clamp(17px, 16px + 0.5vw, 24px); }

  390px Handy -> 17,95px  (bisher 18,00 -- bewusst kein Rueckschritt)
  768px       -> 19,84px
  1440px      -> 23,20px
  ab 1600px   -> 24,00px (Deckel)

Der Anker ist so gesetzt, dass am Handy NICHTS kleiner wird -- der User hat
die Groesse am 24.07. zweimal von Hand hochgesetzt; eine Responsive-Umstellung,
die sie wieder eindampft, waere eine stille Ruecknahme seiner Entscheidung.

Verifiziert statt behauptet:
  - alle 96 Deklarationen gegen die 18px-Referenz zurueckgerechnet,
    groesster Fehler 0,0008 px
  - 93 font-size + 3 font:<weight> Npx/...-Shorthand (.ms-chip/.ms-bos-lbl/
    .sqm-badge -- die waren beim Bump am 24.07. zuerst uebersehen worden)
  - ausgeliefert: 0 px-Schriftgroessen, fluide Wurzel da, HTML zieht v=167

Zwei Vorbedingungen geprueft, nicht angenommen:
  - viewport-Meta ist gesetzt (sonst wuerde vw am Handy ~980px messen)
  - beide Media-Queries stehen in px, verschieben sich also nicht mit der
    Schrift (die klassische em-Falle bei Breakpoints)

Abstaende bleiben in px -- sie mitzuskalieren waere ein weit groesserer
Eingriff mit Layout-Risiko; die Anfrage betraf die Schrift.

Groesse global aendern = jetzt EINE Zeile statt 96 Einzelwerten.
Zurueck: web/style.css.bak-2026-08-13

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

CLAUDE.md

@@ -4315,13 +4315,52 @@ Trader wäre sie nie abgelaufen. Latte unverändert: Verhältnis < 1,0 ODER PF <
   („⚠ 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=158** (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` —
-  die wurden zuerst übersehen, weil das erste Bump-Skript nur `font-size` erfasste)
-  + Chart-`fontSize` in `app.js`. Bei künftigen globalen Font-Änderungen die
-  Shorthand nicht vergessen.
+- Asset-Version aktuell **v=167** (in `web/index.html` hochzählen, siehe Workflows).
+- **✅ SCHRIFT SKALIERT MIT DEM FENSTER (2026-08-13, v=167).** User: „die Größe der
+  Schriftarten im Dashboard auf em einstellen, damit auf jedem Gerät oder je nach
+  Fenstergröße die Schriftgröße automatisch angepasst wird."
+  ⚠⚠ **Umgesetzt mit `rem` + fluider WURZEL, NICHT mit `em` — der Wunsch war
+  richtig, die genannte Einheit nicht.** `em` ist relativ zum **Eltern**element und
+  reagiert auf die Fenstergröße **gar nicht**; verschachtelt multipliziert es sich
+  sogar (ein `h2` mit 1,2em in einer Karte mit 1,1em landet bei 1,32×). `rem` hängt
+  dagegen an genau EINER Stellschraube, und die wird fluide gemacht:
+  ```css
+  html { font-size: clamp(17px, 16px + 0.5vw, 24px); }
+  ```
+  | Fenster | Wurzel | Basistext (heute 18px) | klein (11px) | groß (26px) |
+  |---|---|---|---|---|
+  | 360px | 17,80 | 17,8 | 10,9 | 25,7 |
+  | **390px (Handy)** | **17,95** | **17,9** | **11,0** | **25,9** |
+  | 768px | 19,84 | 19,8 | 12,1 | 28,6 |
+  | 1440px | 23,20 | 23,2 | 14,2 | 33,5 |
+  | ab 1600px | 24,00 (Deckel) | 24,0 | 14,7 | 34,7 |
+  ⚠ **Der Anker ist bewusst so gesetzt, dass am Handy NICHTS kleiner wird** — 17,95
+  gegen bisher 18,00px. Der User hat die Größe am 24.07. zweimal von Hand
+  hochgesetzt; eine „Responsive-Umstellung", die sie wieder eindampft, wäre eine
+  stille Rücknahme seiner Entscheidung. Es wird also nur nach oben skaliert.
+  ✅ **Umrechnung verlustfrei belegt**, nicht behauptet: alle **96** Deklarationen
+  gegen die 18px-Referenz zurückgerechnet, größter Fehler **0,0008 px**.
+  ⚠ Die drei `font:<weight> Npx/…`-**Shorthands** (`.ms-chip`/`.ms-bos-lbl`/
+  `.sqm-badge`) sind **mit** umgestellt — sie waren beim Bump 2026-07-24 zuerst
+  übersehen worden, weil ein Skript nur `font-size` erfasste. Prüfsumme: 93
+  `font-size` + 3 Shorthand = 96, ausgeliefert **0** px-Schriftgrößen.
+  ✅ **Zwei Vorbedingungen geprüft, nicht angenommen:** (a) `<meta name="viewport"
+  content="width=device-width…">` ist gesetzt — ohne ihn würde `vw` am Handy den
+  Layout-Viewport (~980px) messen und die Schrift wäre dort riesig; (b) die beiden
+  Media-Queries (360/560px) stehen in **px** und verschieben sich damit **nicht**
+  mit der Schrift. Wären sie in `em`, würde ein größerer Text die Breakpoints
+  wandern lassen — die klassische Falle.
+  ⚠ **ABSTÄNDE bleiben in px** (Padding/Margin/Grid). Sie mitzuskalieren wäre ein
+  weit größerer Eingriff (Karten, Grid, Trade-Leiste) mit echtem Layout-Risiko; die
+  Anfrage betraf die Schrift. Folge: auf sehr breiten Fenstern wird der Text relativ
+  zu den Rändern etwas dominanter.
+  ⚠ Die clamp-Grenzen stehen in **px**, nicht in `rem` — dadurch ist die Anzeige
+  vorhersagbar, respektiert aber die im Browser eingestellte Basis-Schriftgröße
+  nicht. Bewusst so, weil der User die Größe zweimal selbst kalibriert hat.
+  **Zurück:** `web/style.css.bak-2026-08-13`. Größe global ändern = **eine** Zeile
+  (die `clamp`), nicht mehr 96 Einzelwerte — genau das war die Schwäche vorher.
+  ⚠ Chart-`fontSize` in `app.js` gibt es **nicht mehr** (mit dem Charts-Tab am
+  05.08. entfallen) — der alte Warnhinweis dazu ist damit gegenstandslos.
 
 ## Hyperliquid-Kurs neben dem Broker-Kurs (2026-08-01)