/* Shell-Chrome-Styles der geteilten AppShell (Adepto.UI.Shell) — von BEIDEN Apps geladen
   (Kunden-App + Admin). Hierher extrahiert aus Adepto.UI/wwwroot/css/app.css (Etappe 5),
   damit die Admin-Shell 1:1 identisch rendert. */

/* --- Hauptinhalt: Platz fuer die fixierte Bottom-Nav (Mobile) --- */
/* Die MobileBottomNav ist `fixed bottom-0` (~53px) und ueberlagert den Inhalt -> ohne Reserve wird der
   untere Seiteninhalt (z.B. Team-Mitgliederliste) verdeckt. Nur unter lg (Nav ist lg:hidden);
   + env(safe-area-inset-bottom) fuer Geraete mit Home-Indicator. */
/* EINE Quelle fuer die Hoehe der Bottom-Nav. Vorher stand die 4rem an drei Stellen (Inhalts-Reserve
   hier, Position der Unsaved-Bar in app.css, implizite Hoehe der Nav selbst) - wer eine davon
   aendert, verschiebt die anderen nicht mit, und der Fehler faellt erst auf dem Geraet auf. */
:root {
    --adepto-bottomnav-h: 4rem;
}

@media (max-width: 1023.98px) {
    .adepto-mobile-navpad {
        padding-bottom: calc(var(--adepto-bottomnav-h) + env(safe-area-inset-bottom));
    }

    /* Die Nav SELBST brauchte diese Reserve auch (Mike-Meldung 09.09.2026: "die Navbar ist zu klein
       und zu weit unten"). Sie ist fixed bottom-0; auf einem Geraet mit Home-Indikator lagen ihre
       Symbole damit in genau dem Streifen, den das Betriebssystem fuer die Wischgeste reserviert.
       Der Inhalt darueber rechnete den Streifen laengst mit ein - nur die Leiste nicht.
       Zusaetzlich eine Mindesthoehe: 53px waren unter jeder gaengigen Empfehlung fuer Tippflaechen
       (Apple 44px, Google 48px - und zwar je Symbol, nicht fuer die ganze Leiste).
       Als eigene Klasse statt Tailwind-Utility, weil die CLI die calc()+env()-Kombination nicht
       erzeugt - dieselbe Falle, die oben schon dokumentiert ist. */
    .adepto-bottomnav {
        min-height: var(--adepto-bottomnav-h);
        padding-bottom: env(safe-area-inset-bottom);
    }
}

/* --- DataGrid-Toolbar: globales Suchfeld verbreitern (PO-Feedback: zu schmal) --- */
/* Lumeo setzt am <input> direkt `max-w-56` (14rem) - Quelle: Lumeo.DataGrid/UI/DataGrid/
   DataGridToolbar.razor (`<div data-slot="datagrid-toolbar">...<div class="relative">
   <input type="text" class="... max-w-56 ...">`). Der Attribut-Selektor hier hat hoehere
   Spezifitaet als die einzelne Tailwind-Utility-Klasse und gewinnt unabhaengig von der
   Stylesheet-Reihenfolge. Nur der Suchfeld-Input traegt type="text" innerhalb der Toolbar -
   die Filter-Chips daneben sind reine <span>/<button>, kein zweiter Treffer moeglich. */
[data-slot="datagrid-toolbar"] input[type="text"] {
    /* width zusaetzlich zu max-width: der Input ist w-full in einem content-sized Wrapper -
       ein reines max-width-Anheben aendert die tatsaechliche Breite dann nicht (im Browser
       gemessen ~238px). Die feste width zwingt auch den Wrapper auf. */
    width: 18rem;
    max-width: 18rem;
}

/* --- Sidebar-Nav volle Breite --- */
/* Lumeos <Tooltip> rendert einen `relative inline-flex`-DIV (content-breit) um den Trigger. Der
   SidebarMenuButton ist intern zwar w-full, kann diesen content-breiten Tooltip-Wrapper aber nicht
   sprengen -> das Active-Highlight bleibt schmal. Tooltip hat keinen Class-Parameter, daher per CSS:
   den Tooltip-Wrapper der Nav-Items (Marker .adepto-nav an der SidebarMenu-<ul>) auf volle Breite. */
.adepto-nav > li > .relative.inline-flex {
    display: flex;
    width: 100%;
}

/* Horizontale Trenner (Sidebar-Header, Sidebar-Footer/Account, Folder-Header, Trash-Footer)
   nicht ganz durchziehen ("weniger blocky"): Linie links/rechts 0.75rem eingerueckt statt randlos
   bis an die vertikalen Spalten-Trenner - die Trennung bleibt sichtbar, die Ecken wirken weicher.
   Die vertikalen Spalten-Linien (border-r) bleiben voll durchgezogen wie in der Referenz. */
.inset-divider-b {
    position: relative;
}
.inset-divider-b::after {
    content: "";
    position: absolute;
    left: 0.75rem;
    right: 0.75rem;
    bottom: 0;
    height: 1px;
    background: var(--color-border);
    pointer-events: none;
}
.inset-divider-t {
    position: relative;
}
.inset-divider-t::after {
    content: "";
    position: absolute;
    left: 0.75rem;
    right: 0.75rem;
    top: 0;
    height: 1px;
    background: var(--color-border);
    pointer-events: none;
}

/* WASM-Boot-Splash: Adepto-Logo + Fortschrittsbalken (Etappe 5.1, aus Kunden-app.css hierher
   verschoben, da BEIDE Apps denselben Splash nutzen - Single Source fuer die geteilte Shell). */
.adepto-splash {
    position: fixed;
    inset: 0;
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 1.5rem;
    background: var(--color-background);
}

.adepto-splash-logo {
    height: 56px;
    width: auto;
}

.adepto-splash-bar {
    width: 200px;
    height: 3px;
    background: var(--color-muted);
    border-radius: 999px;
    overflow: hidden;
}

.adepto-splash-bar-fill {
    height: 100%;
    width: var(--blazor-load-percentage, 5%);
    background: var(--color-primary);
    transition: width 0.2s ease-out;
}

/* Unsaved-Changes-Bar (Discord-Muster, Portal-Savebar-Etappe): Basis-Position + Einblend-Keyframe -
   von Adepto.UI/wwwroot/css/app.css hierher verschoben, da BEIDE Apps (Kunden-App + Admin-Portal) die
   UnsavedChangesBar/UnsavedChangesTracker jetzt aus Adepto.UI.Shell nutzen (siehe dortige Klassen-
   Kommentare). Als eigene Klasse statt bottom-[calc(...)]-Utility, weil die Tailwind-CLI die
   calc()+env()-Kombination nicht generiert (gleiche Falle wie bei .adepto-mobile-navpad).
   Die MOBILE Sonderposition (ueber der fixierten Bottom-Nav) bleibt bewusst in Adepto.UI/wwwroot/
   css/app.css: nur die Kunden-App hat eine MobileBottomNav, das Admin-Portal nicht - dort gilt daher
   auch mobil die Desktop-Position (kein Override noetig). */
.adepto-unsaved-bar {
    bottom: 1.5rem;
}

@keyframes unsaved-bar-in {
    from {
        opacity: 0;
        transform: translateY(0.75rem);
    }
    to {
        opacity: 1;
        transform: translateY(0);
    }
}

/* Chromium-Repaint-Artefakt bei fraktionalem DPR (Windows-Skalierung 125/150%): beim
   Weganimieren von border-/outline-color bleiben Haarlinien-Reste des Fokus-Rings stehen
   (teils ausserhalb der Border-Box). Fokus ist ein diskreter Zustand - Transition auf
   Rahmenfarben von Form-Controls bringt nichts und provoziert nur das Artefakt. */
input:not([type="checkbox"]):not([type="radio"]),
textarea {
    transition-property: color, background-color;
}

/* Lumeo-Bug (mind. seit 4.1.0-preview.4, weiterhin in 4.2.0): lumeo.css setzt fuer JEDES <form>,
   das direktes Kind eines role="dialog"-Overlays ist, `flex: 1 1 0` (Kommentar dort:
   "EditForm-in-Sheet/Dialog flex compatibility" - Zweck: Footer soll in Sheet/Dialog unten pinnen).
   Sheet und Dialog haben dafuer immer eine DEFINITE Hoehe (volle Sheet-Seite bzw. Dialog max-height) -
   Drawer aber nicht: Drawer sized to content (h-auto, nur mit max-h-[96vh] gedeckelt; laut Lumeo-Doku
   "Drawer sizes to its content and ignores [Size]"). flex-basis:0 in einem h-auto-Flex-Container hat
   nichts zum Messen -> das <form> (und damit der gesamte sichtbare Inhalt) kollabiert auf ~0px Hoehe;
   sichtbar bleibt nur der oberste Drag-Handle-Balken (~30px) - der Drawer wirkt komplett leer/unsichtbar.
   Reproduziert + verifiziert per Live-Browser-Test an "Vertrieb kontaktieren" (Adepto.UI, Abrechnung ->
   Overlay.ShowDrawerAsync<EnterpriseInquiryForm> + OverlayPresets.DrawerForm): Panel-Hoehe 30px ohne
   Fix, 373px mit Fix (kurzer Inhalt) bzw. korrekt an 96vh gedeckelt + intern scrollend (Body flex-1
   min-h-0 overflow-y-auto) bei >2000px langem Test-Inhalt.
   Fix: flex-basis zurueck auf `auto` (= Content-Groesse), NUR fuer Drawer (Sheet/Dialog behalten den
   Original-Fix, den sie fuer ihre definite Hoehe weiterhin brauchen). grow:1/shrink:1 bleiben, damit
   ueberlanger Inhalt weiterhin korrekt an max-h-[96vh] gedeckelt wird statt den Drawer zu sprengen.
   shell.css laedt nach lumeo.css -> gleiche Selektor-Spezifitaet, spaetere Regel gewinnt per
   Kaskaden-Reihenfolge (kein !important noetig). Entfernen, sobald Lumeo das nativ fixt. */
[role="dialog"][id^="drawer-"] > form {
    flex: 1 1 auto;
}

/* Mike-Fund 2026-07-22 (Portal-Sidebar H-Scrollbar beim Expanden): Lumeos SidebarContent hat
   overflow-auto auf beiden Achsen. Wird die Nav-Liste hoeher als der Platz (seit den Gruppen-Labels
   moeglich), erscheint die V-Scrollleiste, nimmt Breite weg und die w-full-Eintraege erzeugen einen
   H-Overflow von exakt Leistenbreite. Fix: horizontal hart abschneiden.
   Mike-Fund 2026-07-23 (Icon-Rail schneidet Icons ab, Variant=Icon/eingeklappt): der erste Fix
   reservierte per `scrollbar-gutter: stable` dauerhaft eine Rinne fuer die V-Leiste - in der schmalen
   Icon-Rail (kein Platz fuer Gruppen-Labels-Overflow im Normalfall, aber bei hohem Viewport-Inhalt
   trotzdem V-Overflow moeglich) frisst diese Rinne plus die ggf. sichtbare V-Leiste selbst Breite von
   der Rail und schneidet die Icons rechts ab. Robusterer Fix: keine Rinne reservieren, sondern die
   V-Leiste selbst unsichtbar machen (Inhalt bleibt per Mausrad/Touch scrollbar) - dann kann in keinem
   der beiden Sidebar-Zustaende (expandiert/Icon) Breite verloren gehen. Laedt NACH tailwind.css
   (Link-Reihenfolge beider index.html) -> gewinnt bei gleicher Spezifitaet. */
.adepto-sidebar-content {
    overflow-x: hidden;
    scrollbar-width: none;
}
.adepto-sidebar-content::-webkit-scrollbar {
    display: none;
}

/* Mike-Fund 2026-08-25 (Portal, Dialog "Neue Rabatt-Aktion"): das rechte der beiden Datumsfelder
   ragte ueber den Dialogrand hinaus. GEMESSEN im laufenden Portal: die Grid-Spalte ist 221px breit,
   der DatePicker darin 234px - er sitzt in einem `inline-block`-Wurzelelement mit einem
   `inline-flex`-Ausloeser, beide sizen also auf ihre INHALTSBREITE und ignorieren die Spalte. Die
   Inhaltsbreite kommt vom eingebetteten `<input type=text>` (Browser-Standard ~192px) plus
   Innenabstand und Kalender-Symbol. Lumeo 5.0.0 hat den Ausloeser auf eine eigene Flex-Zeile
   umgestellt ('group flex h-8 w-full items-center rounded-md border ...', in 4.3.3 nicht vorhanden) -
   das `w-full` darin zeigt, dass der Ausloeser die Spalte FUELLEN soll; nur die beiden
   content-sizenden Huellen darueber lassen das nicht zu.
   Die Kunden-App hat dafuer laengst eine Loesung (Adepto.UI/wwwroot/css/app.css, Klasse `adepto-dp`,
   dort fuer Zertifikats-/Team-Formulare). Sie steht hier NOCH EINMAL, weil sie ins geteilte shell.css
   gehoert: das Portal laedt app.css der Kunden-App nicht. Die dortige Kopie bleibt vorerst
   unveraendert stehen (identische Deklarationen, daher wirkungsgleich) - sie zu entfernen waere eine
   Aenderung an der Kunden-App, die zu diesem Fund nicht gehoert.
   WICHTIG (aus dem dortigen Kommentar uebernommen und hier nachgeprueft): Lumeo legt die
   DatePicker-`Class` auf den AUSLOESER, nicht auf die Wurzel - also KEIN `display` setzen (der
   Ausloeser muss flex bleiben, sonst stapeln sich Eingabefeld und Symbol untereinander), nur
   schrumpfbar machen. Die beiden content-sizenden Huellen per :has() auf volle Spaltenbreite ziehen. */
.adepto-dp {
    min-width: 0;
}

.adepto-dp input {
    min-width: 0;
}

.inline-flex:has(> .adepto-dp) {
    display: flex;
    width: 100%;
    min-width: 0;
}

.inline-block:has(> .inline-flex > .adepto-dp) {
    display: block;
    width: 100%;
}

/* Mike-Fund 2026-08-25 (Portal, /bewerbungen/{id}): "der Title Text pro card ist zu nah am card top".
   GEMESSEN im laufenden Portal: die Karte selbst hat KEINEN Innenabstand (padding 0), ihr
   Inhaltsbereich (Lumeos CardContent) traegt `p-6 pt-0` - also 24px links/rechts/unten, aber 0 oben.
   Das ist ABSICHT der Bibliothek und in BEIDEN Versionen gleich (CardContent-Doku 4.3.3 und 5.0.0
   wortgleich: "rendered below the header ... but no top padding (it abuts CardHeader's bottom
   spacing)"). Es ist also KEIN 5.0.0-Rueckschritt: CardContent setzt voraus, dass eine CardHeader
   darueber steht und den oberen Abstand liefert. Zur Gegenprobe an einer Karte MIT CardHeader
   gemessen (/finanzen): dort hat die Kopfzeile 'flex flex-col space-y-1.5 p-6' und oben korrekte 24px.
   Betroffen sind genau die Karten, die - wie ApplicationDetailPage und weitere Portalseiten - ohne
   CardHeader gebaut sind und ihre Ueberschrift direkt in den Inhaltsbereich legen: deren erste Zeile
   klebt dann an der Kartenkante.
   Zentraler Fix statt Karte-fuer-Karte: nur wenn der Inhaltsbereich das ERSTE Kind der Karte ist
   (:first-child = keine CardHeader davor), bekommt er seinen oberen Abstand zurueck - passend zu dem
   Wert, den er seitlich ohnehin schon hat. Karten MIT CardHeader treffen die Regel nicht und bleiben
   unveraendert (kein doppelter Abstand). Alle drei Dichtestufen abgedeckt, die Lumeo fuer
   CardContent kennt (p-4/p-6/p-8). shell.css laedt nach lumeo.css - die zusaetzliche Klasse und
   :first-child machen die Regel ohnehin spezifischer als Lumeos einzelnes `.pt-0`.
   Sauberere Alternative fuer spaeter (bewusst NICHT in diesem Durchgang): die betroffenen Seiten auf
   <CardHeader><CardTitle> umstellen - das waere die von der Bibliothek vorgesehene Struktur, betrifft
   aber viele Dateien und mehr als den gemeldeten Fund. */
.rounded-xl.bg-card > .p-4.pt-0:first-child { padding-top: 1rem; }
.rounded-xl.bg-card > .p-6.pt-0:first-child { padding-top: 1.5rem; }
.rounded-xl.bg-card > .p-8.pt-0:first-child { padding-top: 2rem; }

/* Mike-Fund 2026-09-04 (iPhone 17 Pro Max): Icon-Buttons, Buttons, Inputs und Tab-Leisten sind auf dem
   Handy viel zu klein zum Treffen. Lumeos Standarddichte (Density.Comfortable) ist eine Maus-Skala -
   32px hohe Buttons/Inputs/Select-Trigger, 16px-Glyphen, eine 32px-TabsList - weit unter Apples eigener
   Empfehlung von 44pt Tippflaeche (Human Interface Guidelines, "Hit Targets"). GEMESSEN per bUnit gegen
   Lumeo 5.10.0 (nicht geraten): Button/Input/SelectTrigger lesen ihre Hoehe aus genau den vier
   --lumeo-control-h*-Variablen unten (mit Fallback auf die 32/28/24/36px-Skala) - EIN Hebel fuer alle
   Lumeo-Bedienelemente, weil shell.css nach lumeo.css laedt (index.html beider Apps) und eine
   :root-Definition hier deren Fallback-Werte per Kaskaden-Reihenfolge ueberschreibt.
   NICHT ueber diese Variablen gesteuert (feste Tailwind-Klassen in der Lumeo-DLL, geprueft per bUnit-
   Markup-Dump): TabsList (role="tablist", fest h-8, kein Size-Parameter), Checkbox (role="checkbox",
   fest h-4 w-4) und Switch (role="switch", Bahn h-5 w-9 + Daumen h-4 w-4 mit fest verdrahteter
   Tailwind-Klasse translate-x-4 fuer die Checked-Position) - fuer die drei je eine eigene Regel.
   Nur unter (pointer: coarse), damit sich am Desktop (Maus/Trackpad, feine Pointer-Praezision)
   NICHTS aendert - das Kriterium ist Touch, nicht Fensterbreite (ViewportService/Tailwind-Breakpoints
   waeren hier der falsche Hebel: ein schmales Desktop-Fenster hat trotzdem eine Maus).
   Nachtrag 2026-09-15 (Mike, iPhone 17 Pro Max, Instagram-Vergleich): "bisschen zu klobig" - 44px war
   zu grosszuegig fuer dichte Formulare. Nachgemessen an Mikes Instagram-Screenshots: Suchfeld 34pt,
   Knoepfe 29pt, untere Nav-Icons 24pt - alles klar unter unseren 44px.
   Zweiter Nachtrag, selber Tag ("aber die Buttons sind auch viel zu gross"): NOCH eine Stufe kleiner,
   direkt auf Instagrams eigenes Mass (Knoepfe 29pt, Suchfeld 34pt) statt auf einen Kompromisswert
   darueber. Apples 44pt (Human Interface Guidelines) sind eine Empfehlung fuer die ZIEL-Tippflaeche,
   nicht eine Vorschrift fuer den sichtbaren Rahmen - die Tippflaeche entsteht in der Praxis ueber den
   Zeilenabstand und Innenabstand der umgebenden Zeile/Card (die ohnehin schon Griff-Puffer dazugibt),
   nicht ueber die Kastenhoehe selbst. Instagram (ein ausgereiftes Touch-Produkt) faehrt durchgehend auf
   dieser kleineren Skala. Entscheidung Mike, 15.09.2026. */
@media (pointer: coarse) {
  :root {
    --lumeo-control-h: 2.25rem;      /* 36px: Button (Default), Icon-Button, Input, SelectTrigger -
                                         Instagrams eigenes Knopf-/Feld-Mass (29-34pt) */
    --lumeo-control-h-sm: 2rem;      /* 32px */
    --lumeo-control-h-xs: 1.75rem;   /* 28px: Xs-Knoepfe in dichten Listen (kompaktester Button bleibt
                                         kompakt - eine Stufe unter Sm, wie am Desktop) */
    --lumeo-control-h-lg: 2.5rem;    /* 40px: Lg fuer alleinstehende Knoepfe ohne den Griff-Puffer
                                         einer umgebenden Zeile */
    --lumeo-icon-size: 1.25rem;      /* 20px Glyphe unveraendert - bleibt lesbar auch in der kleineren
                                         36px-Flaeche, kein Instagram-Fund dazu */
  }

  /* TabsList: role="tablist", DLL-Klasse fest "h-8" (32px), kein Size-Parameter zum Umgehen. Mit dem
     zweiten Nachtrag auf 40px mitgesenkt (vorher 44px) - bleibt aber eine Stufe UEBER --lumeo-control-h
     (36px): das ist die Navigationsleiste, kein einzelnes Bedienelement mit Zeilen-Puffer daneben. */
  [role="tablist"] {
    height: 2.5rem;
  }

  /* Checkbox: role="checkbox", DLL-Klasse fest "h-4 w-4" (16px). Bewusst NICHT auf 44px, sondern auf
     24px - eine Checkbox steht praktisch nie freistehend, sondern in einer Zeile mit eigenem Label
     (FormField/ListItem), die Zeile selbst liefert die 44px-Tippflaeche. 24px ist trotzdem deutlich
     leichter zu treffen als 16px, ohne das Kaestchen optisch zu einem eigenstaendigen Button aufzublasen. */
  [role="checkbox"] {
    height: 1.5rem;
    width: 1.5rem;
  }

  /* Switch: role="switch", Bahn fest "h-5 w-9" (20x36px), Daumen fest "h-4 w-4" (16px) mit fest
     verdrahteter Tailwind-Klasse "translate-x-4" fuer die Checked-Position (KEINE CSS-Variable - per
     bUnit-Markup-Dump verifiziert). Bahn allein vergroessern wuerde den Daumen im Checked-Zustand vor
     dem rechten Rand haengen lassen ("haengt links"), weil translate-x-4 unveraendert bei 1rem/16px
     bliebe. Deshalb Bahn UND Daumen UND die Checked-Verschiebung zusammen skaliert, mit derselben
     Fuellungs-Logik wie im Original (Daumen fuellt die Bahn abzueglich der 2px-Border auf beiden Seiten
     exakt aus): neue Bahn 1.75rem x 3rem (28x48px, Border 2px+2px) -> Innenmass 24x44px; neuer Daumen
     1.5rem (24px, exakte Hoehe-Fuellung wie im Original) -> Wegstrecke bis zum rechten Rand
     44px - 24px = 20px = 1.25rem. */
  [role="switch"] {
    height: 1.75rem;
    width: 3rem;
  }
  [role="switch"] > span {
    height: 1.5rem;
    width: 1.5rem;
  }
  [role="switch"] > span[data-state="checked"] {
    translate: 1.25rem 0;
  }

  /* Icon-Tabs (Tabs mit IconReveal="true", z.B. TeamDetailPage-Tableiste auf Mobile): role="tab",
     DLL-Klasse fest "px-1.5 py-0.5 h-[calc(100%-1px)]" - die Hoehe folgt bereits der TabsList
     (die "[role=tablist]"-Regel oben haelt sie jetzt bei 40px), aber die Breite bleibt bei px-1.5
     (6px Innenabstand) um eine einzelne Glyphe - bei nur einer 20px-Glyphe (coarse --lumeo-icon-size)
     unter 32px breit. GEMESSEN per bUnit-Markup-Dump gegen Lumeo 5.10.0. */
  [role="tab"] {
    min-width: 2.5rem;
  }

  /* Nachtrag 2026-09-15 (Mike: "die Tab-Navigation hat viel zu kleine Icons"): die Glyphe selbst
     bleibt bei der normalen --lumeo-icon-size (20px), weil TabsTrigger sie ueber eine einzelne
     Size.Sm-Klasse am <Icon> setzt (size-4/h-4 w-4, 16px, GEMESSEN per bUnit) - das ist ausserhalb
     dieser Regel schlicht zu klein fuer eine alleinstehende Tab-Glyphe (kein Text daneben, anders
     als z.B. ein Button-Icon). Element- + Attribut-Selektor ("[role="tab"] svg") schlaegt die
     einzelne Tailwind-Klasse per Spezifitaet unabhaengig von deren Reihenfolge im class-Attribut -
     24px, an Instagrams eigenen Nav-Icons (24pt) gemessen. */
  [role="tab"] svg {
    width: 1.5rem;
    height: 1.5rem;
  }

  /* ToggleGroupItem (Grid/Karte-Umschalter TrainingPage, weitere Segmented-Controls): trägt KEINE
     Rolle (data-toggle-item="true"/aria-pressed statt role="radio") und liest die
     --lumeo-control-h-Variable NICHT - DLL-Klasse fest "h-8 px-2.5" (per bUnit-Markup-Dump
     verifiziert: "bg-accent text-accent-foreground h-8 px-2.5 ..."). shell.css laedt nach
     tailwind.css -> gleiche Spezifitaet (ein Attribut- vs. ein Klassen-Selektor), Kaskaden-
     Reihenfolge entscheidet zu unseren Gunsten wie bei den anderen Regeln in diesem Block. */
  [data-slot="toggle-group-item"] {
    height: 2.25rem;
  }

  /* Karte (Training-Kartenansicht, Lumeo.Maps/MapLibre GL): Zoom +/-, Ortungs-Knopf, Vollbild
     sitzen in .maplibregl-ctrl-group-Buttons, fest 32x32px (map.css der Bibliothek, !important -
     dieselbe !important-Antwort ist hier notwendig, siehe Dark-Theme-Block unten). Das Suchfeld
     ".lumeo-map-search" hat keine feste Hoehe, nur 6px Innenabstand um den <input> -> auch das
     unter 36px. map.js haengt map.css per <link> ERST BEIM KARTEN-MOUNT ans <head> (spaeter als
     shell.css im DOM) - ohne !important wuerde die Bibliothek unsere Regel unabhaengig von der
     Selektor-Reihenfolge im Quelltext ueberschreiben. */
  .maplibregl-ctrl-group > button {
    width: 2.25rem !important;
    height: 2.25rem !important;
  }
  .lumeo-map-search-input-wrap {
    min-height: 2.75rem;
  }
}

/* Mike-Fund 2026-09-15 (iPhone-Screenshots, Training-Kartenansicht): Zoom +/-, Ortungs-Knopf und
   Suchfeld bleiben auf der dunklen Karte WEISS - unabhaengig vom Touch-Fund oben, denn das ist kein
   Groessen-, sondern ein Farb-Fehler und tritt daher auch am Desktop im Dunkelmodus auf (deshalb HIER,
   ausserhalb von @media (pointer: coarse)).
   URSACHE (geprueft in Lumeo.Maps 5.10.0/staticwebassets/css/map.css): die Bibliothek versucht die
   Controls bereits zu themen - "background: hsl(var(--card, ...))" usw. - aber sie erwartet shadcn's
   NACKTE HSL-Kanaltripel-Variablen ("--card: 222 47% 11%"), waehrend diese App ihre Tokens
   "--color-card" nennt und darin VOLLE oklch()-Werte speichert (siehe theme.css). Der Name UND das
   Format passen nicht zusammen -> var(--card) findet nichts, jede Regel faellt auf ihren hartkodierten
   Hell-Default zurueck, unabhaengig vom aktiven Dunkelmodus. Fix: dieselben Selektoren mit den ECHTEN
   App-Variablen ("--color-*", direkt als var() ohne hsl()-Wrapper, da bereits volle Farben) - nur unter
   ":where(.dark, .dark *)" (identisch zu Tailwinds eigenem "dark:"-Custom-Variant in input.css: ".dark"
   sitzt auf <html>, siehe orgtheme.js isDark()). !important wie oben begruendet (map.css selbst nutzt
   !important und laedt spaeter). Icon-Glyphen (Zoom/Locate/Vollbild) sind MapLibre-Standard-SVGs als
   Hintergrundbild, fest schwarz verdrahtet - Lumeo.Maps' eigener ".maplibregl-ctrl-icon { filter: none }"
   ist toter Code (der Kommentar dort spricht von "mask mit currentColor", die Regel tut das nicht,
   geprueft: kein Bezug in map.js). Auf dem jetzt dunklen Panel-Hintergrund waeren schwarze Glyphen
   unsichtbar -> invert(1) macht sie weiss. */
:where(.dark, .dark *) .maplibregl-ctrl-group {
  background: var(--color-card) !important;
  border-color: var(--color-border) !important;
}
:where(.dark, .dark *) .maplibregl-ctrl-group > button {
  color: var(--color-card-foreground) !important;
  border-bottom-color: var(--color-border) !important;
}
:where(.dark, .dark *) .maplibregl-ctrl-group > button:hover {
  background: var(--color-accent) !important;
  color: var(--color-accent-foreground) !important;
}
:where(.dark, .dark *) .maplibregl-ctrl-group > button:active {
  background: var(--color-muted) !important;
}
:where(.dark, .dark *) .maplibregl-ctrl-group .maplibregl-ctrl-icon {
  filter: invert(1);
}
:where(.dark, .dark *) .lumeo-map-search {
  background: var(--color-card) !important;
  border-color: var(--color-border) !important;
}
:where(.dark, .dark *) .lumeo-map-search input {
  color: var(--color-card-foreground);
}
:where(.dark, .dark *) .lumeo-map-search input::placeholder {
  color: var(--color-muted-foreground);
}
:where(.dark, .dark *) .lumeo-map-search-input-wrap svg {
  color: var(--color-muted-foreground);
}
:where(.dark, .dark *) .lumeo-map-search-results {
  border-top-color: var(--color-border);
}
:where(.dark, .dark *) .lumeo-map-search-results button {
  color: var(--color-card-foreground);
}
:where(.dark, .dark *) .lumeo-map-search-results button:hover {
  background: var(--color-accent);
}
:where(.dark, .dark *) .lumeo-map-search-empty {
  color: var(--color-muted-foreground);
}