/* Design-Tokens (docs/022): Neutralskala + Gold-Familie ergaenzt die bestehenden Navy/Gold-
   Werte. Vorher stand der Seitenhintergrund (frueher #eef1f5, R238/G241/B245 - Blau der
   staerkste Kanal, kein neutrales Grau) als Literal da, und praktisch jeder Rahmen/Schatten im
   Interface war rgba(11, 37, 69, X) - durchsichtiges Navy statt neutralem Grau/Schwarz. Das war
   der eigentliche Grund fuer den durchgaengigen Blaustich, nicht nur der Hintergrund allein.
   --rec-bg ist jetzt echtes Neutral (R=G=B), --rec-border/--rec-border-strong/--rec-shadow/
   --rec-shadow-strong ersetzen die verstreuten rgba(11,37,69,X)-Werte ueberall dort, wo sie
   reine UI-Chrome (Rahmen, Trennlinien, Elevation) waren - NICHT dort, wo Navy als bewusster
   Icon-Akzent-Hintergrund diente (--rec-navy-tint, z. B. Icon-Kreise), das bleibt Absicht. */
:root {
    --rec-navy: #0b2545;
    --rec-navy-dark: #061a33;
    --rec-navy-light: #16406e;
    --rec-gold: #c9a227;
    --rec-gold-light: #e2c56b;
    /* Abgedunkelte Gold-Variante fuer Text auf hellen Gold-Flaechen (z. B. Annahme-Badge,
       Hero-Kicker) - --rec-gold selbst hat dort nur 2,05:1 Kontrast (gemessen, WCAG-Fehlschlag),
       diese Variante 6,05:1 auf Weiss bzw. 5,12:1 auf der Gold-Wash-Flaeche (beides AA-konform).
       Bewusst NICHT dasselbe wie die Mietrendite-Bewertungsskala (#b58900) - das ist eine
       eigenstaendige, semantische Statusfarben-Familie (siehe docs/022), keine Gold-Variante. */
    --rec-gold-dark: #7a5f14;

    /* Farbumkehrung (docs/024, finanzfluss-Vergleich Nachtrag): Seitenhintergrund jetzt Weiss statt
       Grau - die vorherige Logik (Seite grau, Karten weiss) drehte finanzfluss um: dort heben sich
       die Eingabe-/Inhaltsflaechen als "hier passiert etwas" vom weissen Seitenhintergrund ab,
       statt dass die ganze Seite grau wirkt. --rec-card-bg (NEU) bezeichnet seither die
       Kartenflaeche statt der Seitenhintergrund - siehe eigener Nachtrag weiter unten fuer den
       finalen Grauton (#f5f5f5) und dessen Herleitung. --rec-surface bleibt Weiss, bezeichnet ab
       jetzt aber gezielt die "hervorgehobene" Flaeche (Ergebnis-Karten, Tooltips/Popover) statt
       der allgemeinen Kartenflaeche.

       --rec-border-strong Nachtrag: Eingabefelder (.material-input) hatten zwischenzeitlich keinen
       eigenen Feldhintergrund (Variante 1, seither zurueckgenommen - Felder sind wieder weiss,
       siehe cashflow-shared.css) - #828282 kam damals auf 3,31:1 gegen --rec-card-bg (WCAG-1.4.11-
       Schwelle 3:1) und bleibt auch jetzt gegen Weiss bei 3,84:1 (Feld-Rahmen,
       .field-tooltip-popover-Rahmen), unabhaengig vom Kartenton unten.

       --rec-card-bg Nachtrag (docs/024, "Karten sind noch zu grau"): #eeeeee (Delta 17 von 255 zu
       Weiss) war zu deutlich - Vorgabe war "nur so viel, dass sie sich gerade eben abheben".
       Zwei Abstufungen geprueft (#f5f5f5, Delta 10, vs. #f8f8f8, Delta 7) - #f5f5f5 gewaehlt:
       #f8f8f8 waere auf Displays mit abweichender Farbwiedergabe oder bei Sonnenlicht am Handy
       praktisch verschwunden, 10 Stufen sind subtil genug und bleiben verlaesslich sichtbar.
       #f5f5f5 ist zudem kein neuer Wert - derselbe Grauton lief bereits vor dieser Farbumkehrung
       als Seitenhintergrund (siehe Kommentar oben), bereits einmal als "gerade richtig hell"
       bestaetigt. --rec-text-muted darauf: 4,89:1 (AA-konform, Schwelle 4,5:1). */
    --rec-bg: #ffffff;
    --rec-surface: #ffffff;
    --rec-card-bg: #f5f5f5;
    --rec-border: #dcdcdc;
    --rec-border-strong: #828282;
    --rec-shadow: rgba(0, 0, 0, 0.08);
    --rec-shadow-strong: rgba(0, 0, 0, 0.16);
    --rec-text-muted: #6b6b6b;
    --rec-text-subtle: #a3a3a3;
    /* Bewusst weiterhin Navy-getoent (nicht neutral): Icon-Kreise/Icon-Buttons, deren Icon selbst
       Navy ist - ein neutral-grauer Chip hinter einem Navy-Icon wuerde die beiden voneinander
       loesen statt als ein zusammengehoeriges "farbiges Icon-Chip"-Element zu wirken. */
    --rec-navy-tint: rgba(11, 37, 69, 0.07);
}

html, body {
    font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;
    background-color: var(--rec-bg);
}

h1, h5 {
    color: var(--rec-navy);
}

h1:focus {
    outline: none;
}

a, .btn-link {
    color: var(--rec-navy);
}

.btn-primary {
    color: #fff;
    background-color: var(--rec-navy);
    border-color: var(--rec-navy);
}

.btn-primary:hover, .btn-primary:focus {
    background-color: var(--rec-navy-light);
    border-color: var(--rec-navy-light);
}

/* Bootstrap backt Komponentenfarben in eigene --bs-btn-*-Variablen je Klasse ein (nicht in
   --bs-primary) - daher hier gezielt .btn-outline-primary ueberschrieben statt --bs-primary global
   zu setzen. Betrifft in dieser App den "Laden"-Button (Historie) und die Betrag/Prozent-Toggle-
   Buttons (Cashflow-Formular). */
.btn-outline-primary {
    --bs-btn-color: var(--rec-navy);
    --bs-btn-border-color: var(--rec-navy);
    --bs-btn-hover-color: #fff;
    --bs-btn-hover-bg: var(--rec-navy);
    --bs-btn-hover-border-color: var(--rec-navy);
    --bs-btn-active-color: #fff;
    --bs-btn-active-bg: var(--rec-navy);
    --bs-btn-active-border-color: var(--rec-navy);
    --bs-btn-disabled-color: var(--rec-navy);
    --bs-btn-disabled-border-color: var(--rec-navy);
}

.btn:focus, .btn:active:focus, .btn-link.nav-link:focus, .form-control:focus, .form-check-input:focus {
  box-shadow: 0 0 0 0.1rem white, 0 0 0 0.25rem var(--rec-gold-light);
}

.form-control:focus {
    border-color: var(--rec-gold);
    box-shadow: 0 0 0 0.25rem rgba(201, 162, 39, 0.25);
}

/* Der graue Trennstrich unter dem Laender-Tabstreifen (CountryTabs) kam bisher aus Bootstraps
   Standard-.nav-tabs{border-bottom} - .nav-tabs traegt "display: flex" (Bootstrap), das macht die
   <ul> zu einem Block-Flex-Container, der wie jeder Block ohne eigene Breitenangabe die volle
   Breite seines Elternelements einnimmt (hier: article, bis zu 1600px) - unabhaengig davon, wie
   viel Platz die drei Tabs selbst brauchen. Die Kartenreihe darunter (.cashflow-card-flow) nimmt
   je nach Kartenzahl aber oft weniger Breite ein, wodurch die Linie eine Seitenbreite anzeigte,
   die sonst nirgends im Layout vorkommt - wirkte wie ein Layoutfehler (Nutzer-Feedback per
   Screenshot, docs/027). Fix: width:fit-content begrenzt die <ul> auf ihre eigene Inhaltsbreite -
   die Linie endet dadurch exakt am letzten Tab statt willkuerlich am Container-Rand. Farbe/Staerke
   explizit auf --rec-border (#dcdcdc, der hellste vorhandene Border-Token) statt Bootstraps
   #dee2e6-Standard, wie gefordert. */
.nav-tabs {
    width: fit-content;
    border-bottom: 1px solid var(--rec-border);
}

.nav-tabs .nav-link.active {
    color: var(--rec-navy);
    font-weight: 600;
    border-bottom: 3px solid var(--rec-gold);
}

.nav-tabs .nav-link:hover {
    color: var(--rec-navy);
}

/* Android-Material-"Elevation": Karten heben sich per Schatten UND per Grauton vom weissen
   Seitenhintergrund ab (siehe --rec-card-bg oben). Seit der Rueckstufung auf #f5f5f5 (Delta nur
   10 von 255) zusaetzlich ein 1px-Rahmen (--rec-border) als Haerte-Test-Ergebnis (docs/024,
   Browser-Gegenpruefung nach dem Grauton-Nachtrag): der Schatten allein wirkte im Screenshot noch
   ausreichend, ist aber ein diffuser, halbtransparenter Cue - genau die Art Signal, die bei
   Blendung/Sonnenlicht oder abweichender Bildschirm-Farbwiedergabe zuerst verschwimmt (derselbe
   Grund, aus dem #f8f8f8 als Kartenfarbe verworfen wurde). Eine scharfe 1px-Kante ist bei
   gleicher Kontrastdifferenz deutlich robuster erkennbar als ein weicher Farbverlauf (Kanten
   werden vom Auge unabhaengig von der reinen Kontraststaerke leichter erfasst). Ergebnis-Karten
   der Rechner durchbrechen das gezielt (siehe cashflow-shared.css, :has(.cashflow-result-row)) -
   der dortige goldene Rahmen oben ueberschreibt nur die Oberseite, die uebrigen drei Seiten
   behalten den duennen grauen Rahmen von hier. */
.card {
    background-color: var(--rec-card-bg);
    border: 1px solid var(--rec-border);
    box-shadow: 0 1px 2px var(--rec-shadow), 0 1px 3px var(--rec-shadow-strong);
}

.table > thead {
    border-bottom: 2px solid var(--rec-gold);
}

.content {
    padding-top: 1.1rem;
}

.valid.modified:not([type=checkbox]) {
    outline: 1px solid #26b050;
}

.invalid {
    outline: 1px solid red;
}

.validation-message {
    color: red;
}

#blazor-error-ui {
    color-scheme: light only;
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    box-sizing: border-box;
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

    #blazor-error-ui .dismiss {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }

.blazor-error-boundary {
    background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTYiIGhlaWdodD0iNDkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIG92ZXJmbG93PSJoaWRkZW4iPjxkZWZzPjxjbGlwUGF0aCBpZD0iY2xpcDAiPjxyZWN0IHg9IjIzNSIgeT0iNTEiIHdpZHRoPSI1NiIgaGVpZ2h0PSI0OSIvPjwvY2xpcFBhdGg+PC9kZWZzPjxnIGNsaXAtcGF0aD0idXJsKCNjbGlwMCkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMzUgLTUxKSI+PHBhdGggZD0iTTI2My41MDYgNTFDMjY0LjcxNyA1MSAyNjUuODEzIDUxLjQ4MzcgMjY2LjYwNiA1Mi4yNjU4TDI2Ny4wNTIgNTIuNzk4NyAyNjcuNTM5IDUzLjYyODMgMjkwLjE4NSA5Mi4xODMxIDI5MC41NDUgOTIuNzk1IDI5MC42NTYgOTIuOTk2QzI5MC44NzcgOTMuNTEzIDI5MSA5NC4wODE1IDI5MSA5NC42NzgyIDI5MSA5Ny4wNjUxIDI4OS4wMzggOTkgMjg2LjYxNyA5OUwyNDAuMzgzIDk5QzIzNy45NjMgOTkgMjM2IDk3LjA2NTEgMjM2IDk0LjY3ODIgMjM2IDk0LjM3OTkgMjM2LjAzMSA5NC4wODg2IDIzNi4wODkgOTMuODA3MkwyMzYuMzM4IDkzLjAxNjIgMjM2Ljg1OCA5Mi4xMzE0IDI1OS40NzMgNTMuNjI5NCAyNTkuOTYxIDUyLjc5ODUgMjYwLjQwNyA1Mi4yNjU4QzI2MS4yIDUxLjQ4MzcgMjYyLjI5NiA1MSAyNjMuNTA2IDUxWk0yNjMuNTg2IDY2LjAxODNDMjYwLjczNyA2Ni4wMTgzIDI1OS4zMTMgNjcuMTI0NSAyNTkuMzEzIDY5LjMzNyAyNTkuMzEzIDY5LjYxMDIgMjU5LjMzMiA2OS44NjA4IDI1OS4zNzEgNzAuMDg4N0wyNjEuNzk1IDg0LjAxNjEgMjY1LjM4IDg0LjAxNjEgMjY3LjgyMSA2OS43NDc1QzI2Ny44NiA2OS43MzA5IDI2Ny44NzkgNjkuNTg3NyAyNjcuODc5IDY5LjMxNzkgMjY3Ljg3OSA2Ny4xMTgyIDI2Ni40NDggNjYuMDE4MyAyNjMuNTg2IDY2LjAxODNaTTI2My41NzYgODYuMDU0N0MyNjEuMDQ5IDg2LjA1NDcgMjU5Ljc4NiA4Ny4zMDA1IDI1OS43ODYgODkuNzkyMSAyNTkuNzg2IDkyLjI4MzcgMjYxLjA0OSA5My41Mjk1IDI2My41NzYgOTMuNTI5NSAyNjYuMTE2IDkzLjUyOTUgMjY3LjM4NyA5Mi4yODM3IDI2Ny4zODcgODkuNzkyMSAyNjcuMzg3IDg3LjMwMDUgMjY2LjExNiA4Ni4wNTQ3IDI2My41NzYgODYuMDU0N1oiIGZpbGw9IiNGRkU1MDAiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPjwvZz48L3N2Zz4=) no-repeat 1rem/1.8rem, #b32121;
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

    .blazor-error-boundary::after {
        content: "An error has occurred."
    }

.app-loading {
    position: fixed;
    inset: 0;
    display: flex;
    flex-direction: column;
    align-items: center;
    justify-content: center;
    gap: 1.25rem;
    background-color: var(--rec-bg);
}

.app-loading-ring {
    position: relative;
    width: 8rem;
    height: 8rem;
}

.app-loading-icon {
    position: absolute;
    inset: 0.9rem;
    display: flex;
    align-items: center;
    justify-content: center;
    border-radius: 50%;
    /* --rec-card-bg statt --rec-surface: der Ladebildschirm-Hintergrund (--rec-bg) ist seit der
       Farbumkehrung (docs/024) selbst Weiss - ein weisser Icon-Kreis waere sonst nur noch per
       Schatten erkennbar. */
    background-color: var(--rec-card-bg);
    box-shadow: 0 2px 8px var(--rec-shadow-strong);
    color: var(--rec-navy);
    font-size: 2rem;
}

.app-loading-title {
    font-size: 1.4rem;
    font-weight: 700;
    color: var(--rec-navy);
    letter-spacing: 0.02em;
}

.loading-progress {
    position: static;
    display: block;
    width: 8rem;
    height: 8rem;
}

    .loading-progress circle {
        fill: none;
        stroke: #e0e0e0;
        stroke-width: 0.6rem;
        transform-origin: 50% 50%;
        transform: rotate(-90deg);
    }

        .loading-progress circle:last-child {
            stroke: var(--rec-gold);
            stroke-dasharray: calc(3.141 * var(--blazor-load-percentage, 0%) * 0.8), 500%;
            transition: stroke-dasharray 0.05s ease-in-out;
        }

.loading-progress-text {
    text-align: center;
    font-weight: 600;
    color: #495057;
}

    .loading-progress-text:after {
        content: var(--blazor-load-percentage-text, "Wird geladen…");
    }

code {
    color: #c02d76;
}

.form-floating > .form-control-plaintext::placeholder, .form-floating > .form-control::placeholder {
    color: var(--bs-secondary-color);
    text-align: end;
}

.form-floating > .form-control-plaintext:focus::placeholder, .form-floating > .form-control:focus::placeholder {
    text-align: start;
}

/* .landing-page hatte frueher eine eigene max-width+margin:0 auto (Home-spezifische Zentrierung).
   Seit docs/021 sitzt die Breitenbegrenzung einheitlich fuer alle Seiten am "article" in
   MainLayout.razor.css (links ausgerichtet, nicht mehr zentriert) - .landing-page bleibt nur noch
   als reiner Scoping-Wrapper fuer die "> h2.landing-group-title"-Kindselektoren unten bestehen,
   ohne eigene Breitenlogik. */

/* Hero als eigene Flaeche im Card-Stil statt nacktem Text auf Seitenhintergrund (Nutzer-
   Feedback: "wirkt unfertig") - wendet das bereits etablierte Elevation-Prinzip von .card
   (weisse Flaeche, dezenter Schatten statt Rahmen) auf eine Stelle an, die bisher keins hatte,
   statt ein neues Muster einzufuehren. Der fruehere goldene Rahmen links (wirkte wie eine
   Zitat-Auszeichnung, wo nichts hervorzuheben war) entfaellt ersatzlos. */
.landing-hero {
    padding: 1.5rem 1.75rem;
    margin-bottom: 1.5rem;
    background-color: var(--rec-card-bg);
    border-radius: 0.75rem;
    box-shadow: 0 1px 2px var(--rec-shadow), 0 1px 3px var(--rec-shadow);
}

/* Kicker-Label: kurz (2-3 Woerter) statt des kompletten Untertitelsatzes in Versalien - ein
   ganzer Satz in gesperrten Grossbuchstaben liest sich schlecht. Farbe bewusst --rec-gold-dark,
   nicht --rec-gold: reines Gold auf der weissen Hero-Flaeche kommt nur auf 2,42:1 Kontrast
   (WCAG-Fehlschlag fuer jede Textgroesse), --rec-gold-dark auf 6,05:1 (AA-konform) - gemessen
   nach der WCAG-Relativluminanz-Formel. text-transform:uppercase auf normal geschriebenem Text
   statt Grossbuchstaben im Markup (barrierefreier fuer Screenreader). */
.landing-hero-kicker {
    margin-bottom: 0.4rem;
    font-size: 0.8rem;
    font-weight: 700;
    letter-spacing: 0.08em;
    text-transform: uppercase;
    color: var(--rec-gold-dark);
}

.landing-hero-heading-row {
    display: flex;
    align-items: center;
    gap: 0.6rem;
}

/* Dasselbe Markenbalken-SVG wie in der Seitenleiste (siehe NavMenu.razor.css), hier auf der
   weissen Hero-Flaeche: reines --rec-gold kommt dort nur auf 2,42:1 (gemessen, WCAG-Fehlschlag
   fuer die 3:1-Schwelle grafischer Objekte nach WCAG 1.4.11) - --rec-gold-dark (6,05:1) statt-
   dessen, dieselbe Begruendung wie beim Hero-Kicker. */
.landing-hero-icon {
    flex-shrink: 0;
    width: 2rem;
    height: 2rem;
}

.landing-hero-icon .brand-icon-bar {
    fill: var(--rec-navy);
}

.landing-hero-icon .brand-icon-bar-accent {
    fill: var(--rec-gold-dark);
}

.landing-hero h1 {
    color: var(--rec-navy);
    margin-bottom: 0.4rem;
}

/* margin-bottom:0, weil landing-hero-sub seit dem Entfernen der Hero-Buttons (Nutzer-Feedback:
   fuehrten nur zu Rechnern, die direkt darunter ohnehin als Karten stehen, "Cashflow berechnen"
   war zudem mehrdeutig geworden mit drei Cashflow-Laenderseiten) das letzte Element im Hero ist -
   ein eigener Abstand haette sich zum ohnehin vorhandenen padding-bottom von .landing-hero addiert
   und dort zu ueberschuessigem Leerraum gefuehrt. */
.landing-hero-sub {
    max-width: 38rem;
    font-size: 0.92rem;
    color: var(--rec-text-muted);
    margin-bottom: 0;
}

/* Abstand zwischen einer Kartenreihe und der naechsten Gruppenueberschrift (Nutzer-Feedback:
   wirkte deutlich groesser als der Abstand innerhalb einer Gruppe, wodurch die Gruppierung
   schwaecher wirkte als beabsichtigt). Zusammen mit .landing-cards' margin-bottom ergibt das den
   vollen Gruppen-Abstand (36px + 36px = 72px vorher, jetzt 20px + 20px = 40px bei 1440px) - beide
   Margins collapsen NICHT (per Messung bestaetigt, additiv), da .landing-cards ein
   Flex-Container ist. Ergebnis bleibt bewusst weiterhin klar groesser als der groesste
   Intra-Gruppen-Abstand (Lead-Text -> Karten, 20px) - Verhaeltnis 2,0 statt vorher 3,6, die
   Staffelung bleibt also erhalten, nur weniger extrem. */
.landing-page > h2.landing-group-title {
    margin-top: 1.25rem;
}

.landing-page > h2.landing-group-title:first-of-type {
    margin-top: 1.5rem;
}

.landing-group-title {
    color: var(--rec-navy);
    font-weight: 700;
    margin-bottom: 0;
    padding-bottom: 0.2rem;
    border-bottom: 2px solid var(--rec-gold);
    display: inline-block;
}

.landing-group-lead {
    max-width: 42rem;
    margin-top: 0.4rem;
    margin-bottom: 1.25rem;
}

/* Flexbox mit wrap statt CSS Grid/starrem Bootstrap row-cols-lg-3 (Nutzer-Feedback). Wichtiger
   Unterschied zu einem naheliegenden ersten Versuch mit CSS Grid auto-fit: Grid legt seine
   Spaltenspuren EINMAL fuer das gesamte Raster fest (alle Zeilen teilen sich dieselben Spuren) -
   eine 4-Karten-Gruppe, von der bei einer bestimmten Breite nur 3 in eine Zeile passen, haette
   die vierte Karte weiterhin einsam und schmal in Zeile 2 stehen lassen (per Messung bestaetigt,
   identisches Symptom wie vorher, nur andernorts). Flexbox verteilt "flex-grow" dagegen PRO ZEILE:
   Karten, die zusammen umbrechen, teilen sich automatisch die dort tatsaechlich uebrige Breite -
   eine einzelne uebrig gebliebene Karte fuellt dadurch ihre Zeile vollstaendig aus, unabhaengig
   davon, wie viele Karten in den Zeilen davor standen. flex-basis:280px ohne obere Grenze ist
   bewusst so gewaehlt (siehe Diskussion): Karten duerfen bei wenigen Elementen pro Gruppe auch
   deutlich breiter als die uebliche Kartengroesse werden. */
.landing-cards {
    display: flex;
    flex-wrap: wrap;
    gap: 1rem;
    margin-bottom: 1.25rem;
}

.landing-cards .card {
    flex: 1 1 280px;
    border: 1px solid var(--rec-border);
    border-radius: 0.5rem;
    box-shadow: 0 1px 3px var(--rec-shadow);
    transition: box-shadow 0.15s ease, border-color 0.15s ease;
}

.landing-cards .card:hover {
    border-color: var(--rec-gold);
    box-shadow: 0 3px 10px var(--rec-shadow-strong);
}

.landing-card-body {
    position: relative;
    padding: 1rem 1.1rem 1.15rem;
}

/* Icon neben statt ueber dem Titel (Nutzer-Feedback): spart pro Karte eine Zeilenhoehe, bei
   mehreren Karten auf einem Handy-Bildschirm spuerbar. min-width:0 auf den Flex-Container ist
   noetig, damit der Titel bei sehr langen Namen (z. B. "Cashflow-Rechner Deutschland") umbrechen
   statt den Icon-Kreis aus der Karte zu draengen - Flex-Items sind ohne das per Default nie
   schmaler als ihr eigener Inhalt (min-width:auto), was hier die Karte gesprengt haette. */
.landing-card-header {
    display: flex;
    align-items: center;
    gap: 0.6rem;
    margin-bottom: 0.3rem;
    min-width: 0;
}

.landing-card-icon-wrap {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 2.5rem;
    height: 2.5rem;
    flex-shrink: 0;
    border-radius: 50%;
    background-color: var(--rec-navy-tint);
}

.landing-card-icon {
    font-size: 1.25rem;
    color: var(--rec-navy);
    margin-bottom: 0;
}

.landing-card-title {
    margin-bottom: 0;
    min-width: 0;
    font-weight: 700;
}

.landing-card-title a {
    color: var(--rec-navy);
    text-decoration: none;
}

.landing-card-title a.stretched-link::after {
    position: absolute;
    inset: 0;
    content: "";
}

.landing-card-title a.stretched-link:focus-visible {
    outline: 3px solid var(--rec-gold);
    outline-offset: 2px;
}

.landing-card-text {
    font-size: 0.875rem;
    line-height: 1.45;
    color: var(--rec-text-muted);
    margin-bottom: 0;
}

.landing-card-arrow {
    position: absolute;
    right: 1rem;
    bottom: 1rem;
    color: var(--rec-gold);
    font-size: 1.1rem;
    opacity: 0.6;
    transition: opacity 0.15s ease;
}

.landing-cards .card:hover .landing-card-arrow {
    opacity: 1;
}

/* Vertikaler Navy-Rahmen links entfaellt aus demselben Grund wie beim Hero (Nutzer-Feedback:
   wirkte wie eine Zitat-Auszeichnung, wo nichts hervorzuheben ist) - die frueher zusaetzliche
   linke Einrueckung (1.25rem) war nur fuer den Rahmen gedacht und faellt mit ihm weg, sonst
   stuende der Block ohne erkennbaren Grund eingerueckt gegenueber allen anderen Abschnitten. */
.landing-methodik {
    margin-top: 0.5rem;
    padding: 1.25rem 0 0.25rem;
    border-top: 1px solid var(--rec-border);
}

.landing-methodik h2 {
    color: var(--rec-navy);
    font-size: 1.1rem;
    font-weight: 700;
}

.landing-methodik h3 {
    color: var(--rec-navy);
    margin-top: 0.25rem;
}

/* Schriftgroesse UNTER Kartentext-Niveau (0.875rem, siehe .landing-card-text) plus gedaempfte
   Textfarbe: der Block sind Detailangaben, die trotz der vorherigen Angleichung an die
   Kartentext-Groesse noch dieselbe Aufmerksamkeit wie die Rechner-Karten darueber banden
   (Nutzer-Feedback) - beide Signale (kleiner UND blasser) zusammen machen die inhaltliche
   Nachordnung eindeutig. --rec-text-muted (#6b6b6b) auf --rec-bg (#eeeeee, Seitenhintergrund,
   dieser Block liegt NICHT auf der weissen Kartenflaeche) misst 4,59:1 - ueber dem
   AA-Schwellwert 4,5:1 fuer Fliesstext dieser Groesse, wenn auch mit wenig Reserve. */
.landing-methodik p,
.landing-methodik-list {
    font-size: 0.8125rem;
    color: var(--rec-text-muted);
}

.landing-methodik p {
    margin-bottom: 0.75rem;
}

.landing-methodik p:last-child {
    margin-bottom: 0;
}

.landing-methodik-list {
    margin: 0 0 0.75rem;
    padding-left: 1.25rem;
}

.landing-methodik-list li {
    margin-bottom: 0.35rem;
}

.landing-methodik-list li:last-child {
    margin-bottom: 0;
}

/* Hero wirkte am Desktop sehr flach im Verhaeltnis zur Fensterhoehe (Nutzer-Feedback) - eigener
   min-width-Breakpoint (Bootstraps "lg", ab dem die Sidebar sowieso erscheint) statt die
   Basis-Werte zu aendern, damit Tablet-Breiten (641-991px) unveraendert bleiben und der separate
   mobile Breakpoint unten weiterhin exakt den kompakten Zustand liefert, um den es beim
   vorherigen Mobile-Fix ging. */
@media (min-width: 992px) {
    .landing-hero {
        padding: 2.5rem 3rem;
    }

    .landing-hero h1 {
        font-size: 3rem;
    }

    .landing-hero-icon {
        width: 2.75rem;
        height: 2.75rem;
    }

    .landing-hero-sub {
        font-size: 1.05rem;
    }

    /* Nutzer-Feedback: die 38rem/42rem-Lesebreiten-Begrenzung war fuer schmale Viewports gedacht
       und brach am Desktop viel zu frueh um (z. B. "Sparplan." allein in Zeile 2, obwohl rechts
       mehrere hundert Pixel frei waren), waehrend die Kartenreihe darunter die volle Breite
       nutzt. Ab diesem Breakpoint keine Begrenzung mehr - die Texte nutzen dieselbe Breite wie
       .landing-page (bzw. .landing-hero/.landing-cards darin), am Handy bleibt es unveraendert. */
    .landing-hero-sub,
    .landing-group-lead {
        max-width: none;
    }
}

@media (max-width: 640px) {
    .landing-hero {
        padding: 1rem 1.1rem;
    }

    /* Getrennt von :first-of-type (siehe unten): nur der Abstand VOR nachfolgenden
       Gruppenueberschriften wird verkleinert (Nutzer-Feedback), der Abstand Hero -> erste
       Ueberschrift bleibt unveraendert bei 1,75rem. */
    .landing-page > h2.landing-group-title {
        margin-top: 1rem;
    }

    .landing-page > h2.landing-group-title:first-of-type {
        margin-top: 1.75rem;
    }

    .landing-group-lead {
        margin-bottom: 1rem;
    }

    .landing-cards {
        margin-bottom: 0.875rem;
    }

    .landing-card-body {
        padding: 0.85rem 0.95rem 1rem;
    }

    .landing-card-icon-wrap {
        width: 2.15rem;
        height: 2.15rem;
    }

    .landing-methodik {
        margin-top: 0.25rem;
        padding: 1rem 0 0.2rem;
    }
}

/* Brotkrumen-Navigation (docs/024, Etappe 3): global statt scoped, weil Breadcrumb.razor eine
   eigene Komponente ist - Blazors scoped CSS aus MainLayout.razor.css wuerde ihr Markup ohne
   ::deep gar nicht erreichen, dasselbe Prinzip wie bei CountryTabs/ScheduleTable/CardGrid, deren
   Klassen ebenfalls global liegen. Zwei Varianten (voll/kompakt), CSS entscheidet per Breakpoint,
   welche sichtbar ist - kein JS noetig. */
.breadcrumb-nav {
    margin-bottom: 0.75rem;
    font-size: 0.8rem;
}

.breadcrumb-list {
    display: flex;
    flex-wrap: wrap;
    list-style: none;
    margin: 0;
    padding: 0;
}

.breadcrumb-item {
    display: flex;
    align-items: center;
    color: var(--rec-text-muted);
}

.breadcrumb-item a {
    color: var(--rec-text-muted);
    text-decoration: none;
}

.breadcrumb-item a:hover {
    color: var(--rec-navy);
    text-decoration: underline;
}

.breadcrumb-item [aria-current="page"] {
    color: var(--rec-navy);
    font-weight: 600;
}

/* Unser Klassenname "breadcrumb-item" kollidiert namentlich mit Bootstraps eigenem
   .breadcrumb-item, dessen Standard-CSS automatisch ein "/"-Pseudoelement vor jedes
   Folgeelement haengt (::before, content: var(--bs-breadcrumb-divider, "/")) - unabhaengig
   davon, ob die umschliessende Liste "breadcrumb" heisst. Wir rendern den sichtbaren Trenner
   ("›") bereits als echtes Element im Markup (.breadcrumb-separator) - Bootstraps zusaetzliches
   Pseudoelement erzeugte dadurch "Home › /Cashflow › /Österreich" (per Screenshot bestaetigt).
   Der Slash steht dabei NUR im generierten ::before-Inhalt, nicht im DOM-Text - ein reiner
   curl-/textContent-Check sieht ihn deshalb nicht, das hat die erste Fehlersuche in die Irre
   gefuehrt. Selektor bewusst identisch zu Bootstraps eigenem (nicht nur ".breadcrumb-item
   ::before") - gleiche Spezifitaet ist noetig, damit unsere spaeter geladene Regel tatsaechlich
   gewinnt, statt dass Bootstraps gleich spezifischer Selektor die Kaskaden-Reihenfolge egal
   welcher Ladereihenfolge weiterhin fuer sich entscheidet. */
.breadcrumb-item + .breadcrumb-item::before {
    content: none;
}

.breadcrumb-separator {
    margin: 0 0.4rem;
    color: var(--rec-text-subtle);
}

/* Kompakte Variante nur am Handy sichtbar - Platzersparnis, Vorbild finanzfluss.de. Beide
   Varianten stehen bewusst gleichzeitig im DOM (kein JS zum Umschalten noetig), CSS blendet
   jeweils eine aus statt display:none dynamisch zu berechnen. */
.breadcrumb-compact {
    display: none;
}

.breadcrumb-compact a {
    color: var(--rec-text-muted);
    text-decoration: none;
    font-size: 0.85rem;
}

@media (max-width: 640px) {
    .breadcrumb-full {
        display: none;
    }

    .breadcrumb-compact {
        display: block;
    }
}

/* FAQ-Akkordeon (FaqAccordion.razor/FaqItem.razor, docs/024 Nachtrag): native <details>/<summary>
   statt eines eigenen Popover-Mechanismus - kein JS noetig, aria-expanded ist implizit an das
   "open"-Attribut gekoppelt. Eigener Pfeil per ::after ersetzt den browser-eigenen
   Dreiecks-Marker (list-style:none + ::-webkit-details-marker:none blenden ihn aus), damit das
   Erscheinungsbild app-weit konsistent bleibt statt browserabhaengig zu variieren. */
.faq-item {
    border-bottom: 1px solid var(--rec-border);
    padding: 0.65rem 0;
}

.faq-item:last-of-type {
    border-bottom: none;
    padding-bottom: 0;
}

.faq-item:first-of-type {
    padding-top: 0;
}

.faq-question {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 0.75rem;
    font-weight: 700;
    color: var(--rec-navy);
    cursor: pointer;
    list-style: none;
}

.faq-question::-webkit-details-marker {
    display: none;
}

.faq-question::after {
    content: "+";
    flex-shrink: 0;
    color: var(--rec-gold-dark);
    font-weight: 700;
    font-size: 1.1rem;
}

.faq-item[open] .faq-question::after {
    content: "−";
}

.faq-answer {
    margin-top: 0.5rem;
    color: var(--rec-text-muted);
    font-size: 0.875rem;
}

.faq-answer p:last-child {
    margin-bottom: 0;
}