iOS-Optik: Rot-Semantik korrigiert, Popup-Radius vereinheitlicht

Zwei unabhaengig vom iOS-Entscheid offene Befunde aus DESIGN_REVIEW_2026-08-13.md
§B behoben:

- .aktion (audi-dashboard-ios.css) fuellte bisher JEDE Aktion rot statt nur
  destruktive - jetzt neutrale --ios-fill-Flaeche fuer die Sekundaeraktion,
  neue .aktion.primaer-Regel traegt die rote Fuellung als einzige Stelle
  (deckt sich mit dem Sekundaer/Primaer/Loeschen-Schema, das die Basis-CSS
  schon vorgibt). Gleiche Ursache auch bei Schalter-Ein-Zustand (jetzt --ok
  gruen statt rot, echtes iOS-Systemgruen) und aktiver Desktop-Sidebar-
  Navigation (Flaeche jetzt neutral, Rot bleibt Text-/Icon-Akzent).
- Zwei Balkensegmente in audi-dashboard-app.js nutzten --red fuer eine
  neutrale Kategorie (Arbeitsweg-Fahrten, Versicherungsbeitrag-Aufteilung) -
  jetzt wie die Nachbarsegmente auf --fg umgestellt.
- .setup-popup/.standortmenu (audi-dashboard.css) hatten 20px als Literal
  statt var(--r-tile) - folgen jetzt dem Token wie alle anderen Kacheln.

Im Docker-Testcontainer verifiziert: Setup-Popup, Einstellungen (mobil und
Desktop-Sidebar), Schalter - korrekte Fuellungen, keine Konsolenfehler.

AGENTS.md

@@ -510,10 +510,24 @@ wraps the web app for iPhone; a PWA home-screen install is the accepted intermed
       purely additive overlay loaded after `audi-dashboard.css` in `_aufbauen()`
       (`audi-dashboard-app.js` ~line 3990) — the Audi-CI base values are still fully intact in the
       unmodified base stylesheet, untouched by this decision. Reverting is just: stop loading the
-      overlay `<link>`. Two findings from the same review are still open and unaffected by this
-      decision (they're implementation bugs, not direction questions): §B red-semantics inversion
-      (`.aktion` fills every primary action red, not just destructive ones) and the `.setup-popup`/
-      `.standortmenu` hardcoded `border-radius: 20px` vs. the new 16px token.
+      overlay `<link>`.
+- [x] Fix the two implementation bugs from the same review, independent of the direction decision
+      above — done 2026-08-13. **§B, red-semantics inversion:** `audi-dashboard-ios.css` `.aktion`
+      no longer fills every action red; base `.aktion` is now a neutral `--ios-fill` secondary
+      button, a new `.aktion.primaer` rule is the only one filled with `--ios-tint` (red), matching
+      the `.aktion`/`.primaer`/`.loeschen` semantics the base stylesheet already defined (outline
+      secondary / filled primary / destructive). Also fixed as part of the same finding: switch
+      on-state now uses `--ok` (iOS system green) instead of red; the desktop-sidebar active-tab
+      background (`.tab.on`) is now the neutral `--ios-fill` instead of a red tint, red stays only
+      as the accent text/icon color; two chart-bar segments in `audi-dashboard-app.js` that used
+      `--red` for a neutral data category ("Arbeitsweg" trips, first segment of the insurance
+      contribution bar) now use `--fg` like their sibling segments. **Radius inconsistency:**
+      `.setup-popup` and `.standortmenu` in `audi-dashboard.css` now reference `var(--r-tile)`
+      instead of a hardcoded `20px` literal, so both track whichever design (iOS 16px or, if
+      reverted, Audi-CI 20px) is actually active. Verified live in `audi_ha_test`: Setup-popup
+      Abbrechen/Speichern and the "Einrichten"/"Setup"/"Fertig" buttons in Einstellungen render with
+      the corrected fills at both mobile and desktop widths, switches render green, no console
+      errors.
 - [ ] Fix remaining documentation drift (statistics claim, README gaps, obsolete TODO comment) —
       text-only changes; INSTALL.md's WLAN/TommiG1 drift and stale variable names were fixed
       2026-08-12 (see section B); `DESIGN_REVIEW_2026-08-13.md` and `REVIEW_main_2026-08-13.md`