/**
 * Baustein herzenslicht/hero-start — Vorspannbreite.
 *
 * BERICHTIGT (Fixrunde 2, unabhängige Prüfung) — zwei Fehler dieser Datei:
 * (1) Sie stand ursprünglich zusammen mit den Knopf-Hover-Regeln in EINER
 * `hero-start.css`, registriert unter ZWEI Blocktypen (`core/paragraph` UND
 * `core/button`). Da `hero-start` beide Blocktypen enthält, lud
 * `wp_enqueue_block_style()` die Datei zweimal komplett — gemessen: zwei
 * eigene `<style id="…">`-Blöcke im ausgelieferten HTML
 * (`hh-core-paragraph-hero-start-css-inline-css` und
 * `hh-core-button-hero-start-css-inline-css`), die `.hh-hero-vorspann`-Regel
 * doppelt, ≈3,6 KB unnötig. Behoben durch Aufteilung in zwei Dateien nach
 * Zuständigkeit — diese hier nur für `core/paragraph`, die Knopf-Hover-Regeln
 * in `hero-start-buttons.css` nur für `core/button`. Kein Block trifft mehr
 * auf zwei Dateien mit überlappendem Inhalt.
 * (2) Die Desktop-Zahl war falsch: „533px / ≈74 Zeichen" — gemessen waren in
 * Wahrheit **512px / 71,8 Zeichen** (dieselben 512px wie in der Vorprüfung
 * zur Erstfassung). Ursache der Abweichung: die eigene Messung lief in einem
 * eigens angelegten, vereinfachten Zwei-Spalten-Testgerüst ohne die volle
 * Hero-Polsterung/-Struktur, nicht am echten `hero-start`-Kontext selbst.
 * Nachgemessen AM ECHTEN Baustein (temporäre Seite, `Range.getClientRects()`,
 * 1859-Zeichen-Fülltext, statische Vergleichselemente statt Live-Mutation —
 * Live-Mutation lieferte für die Zeilenzahl in dieser Sitzung wiederholt
 * unzuverlässige Werte, siehe hero-start.php, Hover-Befund; hier deshalb
 * konsequent vermieden). Eigene Zahlen, WEICHEN von den in der Prüfung
 * genannten (512/442/706px Spaltenbreite) leicht ab — vermutlich
 * Scrollbar-/Rendering-Unterschied dieser Umgebung, die QUALITATIVE Aussage
 * ist dieselbe:
 *   1280px Viewport: Spalte 482px → 62 Zeichen/Zeile ungebremst, UNVERÄNDERT
 *     62 mit 430px-Begrenzung (bei diesem Fülltext verschiebt die schmalere
 *     Breite keinen einzigen Zeilenumbruch — Wortgrenzen-Zufall, mit einem
 *     bewussten Gegencheck auf 250px bestätigt: DORT wechselt die Zeilenzahl
 *     sehr wohl (60 statt 30 Zeilen) — die Messmethode unterscheidet also
 *     zuverlässig, wo ein Unterschied vorliegt).
 *   1000px Viewport: Spalte bereits 420,5px — SCHMALER als die 430px-
 *     Begrenzung selbst; die Begrenzung greift hier gar nicht (natürliche
 *     Breite = begrenzte Breite, beide 420,5px).
 *   700px Viewport (gestapelt, unter dem 781px-Haltepunkt): Spalte 612px →
 *     **80,8 Zeichen/Zeile ungebremst** — eindeutig ÜBER der üblichen
 *     Komfortzone (grob 45–75); mit 430px-Begrenzung konstant 62
 *     Zeichen/Zeile. Bestätigt unabhängig den wichtigsten Befund der Prüfung:
 *     Der stärkste, eindeutigste Nutzen der Begrenzung liegt am gestapelten
 *     Haltepunkt, nicht am Desktop — dort ist der Unterschied bei diesem
 *     Fülltext sogar vernachlässigbar (s. o.), am gestapelten Haltepunkt
 *     dagegen behebt die Begrenzung einen echten, deutlichen
 *     Lesbarkeitsmangel (80,8 → 62 Zeichen/Zeile).
 * Token bleibt `settings.custom.lesetextbreite.hero` = 430px (theme.json).
 *
 * Selektor: Elementselektor-Präfix `body ` erhöht die Spezifität auf 0,1,1
 * und gewinnt damit unabhängig von der Reihenfolge gegen WordPress' eigene
 * `.is-layout-constrained > :where(...)`-Regel (ebenfalls 0,1,0) — siehe
 * Befund S1 aus Aufgabe 3b, hier vorsorglich gleich richtig angewandt.
 * Gegengeprüft am gerenderten Ergebnis: `computedMaxWidth: "430px"`,
 * `renderedWidth: 430`.
 */
body .hh-hero-vorspann {
	max-width: var(--wp--custom--lesetextbreite--hero);
}