Kachelueberschriften bekommen Luft, Profil raeumt ausgemusterte Felder auf

Der Abstand zwischen Kachelueberschrift und erster Inhaltszeile war 0, 10 oder
12px, je nachdem ob das folgende Element einen eigenen oberen Rand mitbrachte.
Bei 0 klebte die Ueberschrift an der Zeile und las sich als deren Beischrift.
Jetzt einheitlich 14px, gesetzt am Kopf selbst - benachbarte Raender fallen
zusammen, vorhandene 10/12 werden also angehoben statt addiert, und absolut
gesetzte Nachbarn wie das Zahnrad bleiben unberuehrt. Nur die erste
Beschriftung einer Kachel: .label/.ads-eyebrow tragen auch Inhaltszeilen wie
die Anschrift des Autohauses, die bleiben unveraendert.

Der urspruengliche Auftrag lautete "Panel wie App setzen" und beruhte auf einer
Falschaussage von mir: ich hatte die 10px-Grossschrift aus dem Design-System
gelesen statt die App zu messen. Die App ueberschreibt sie dort absichtlich auf
den Panel-Wert; beide waren laengst identisch.

Dazu: _profil_aufraeumen() entfernt ausgemusterte Profilfelder einmalig beim
Start, Anlass ist fahrzeug.hauptuntersuchung_faellig. Ohne das bliebe der tote
Schluessel fuer immer stehen, weil beide Oberflaechen das Profil vollstaendig
zurueckschreiben. An der Testinstanz geprueft, einschliesslich zweitem Start
ohne Schreibvorgang.

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

AGENTS.md

@@ -11598,3 +11598,69 @@ Der eigentliche Grund auf der **realen** Instanz ist ein anderer und heute
 zuerst gefunden worden: dort wurden ueberhaupt keine Fahrten erkannt, weil die
 Erkennung still das Trip-Signal des Dongles bevorzugte, das nie ankam. Ohne
 Fahrten kein Radstand.
+
+## CT. Kachelueberschriften: der Abstand war das Problem, nicht die Schrift (2026.9.5.11)
+
+Auftrag: *"Kachelueberschriften im Panel wie in der App setzen"*. Der Auftrag
+beruhte auf einer Falschaussage von mir - ich hatte behauptet, die App setze
+dort 10px in Grossschrift mit 0.2em Sperrung. Das steht so im **Design-System**,
+das die App an dieser Stelle aber absichtlich ueberschreibt. Live gemessen sind
+beide identisch:
+
+| | Panel `.label` | App `.ads-eyebrow` |
+|---|---|---|
+| Groesse | 13px | 13px |
+| Gewicht | 400 | 400 |
+| Farbe | rgb(142,142,147) | rgb(142,142,147) |
+| Grossschrift | nein | nein |
+| Sperrung | 0.13px | 0.13px |
+
+`companion-app/src/stile/audi-schrift.css` traegt die Begruendung seit dem
+29.08.2026: die App soll optisch moeglichst identisch zum Panel sein. "Panel wie
+App" waere also folgenlos geblieben. **Lehre: die gerenderte Oberflaeche messen,
+nicht die Quelle des Pakets lesen** - dieselbe Verwechslung wie beim
+Ringe-Fehlalarm in Abschnitt CS, am selben Tag.
+
+### Was tatsaechlich fehlte
+
+Der Abstand zwischen Ueberschrift und erster Inhaltszeile haengt davon ab, ob
+das folgende Element zufaellig einen eigenen oberen Rand mitbringt. Gemessen
+ueber fuenf Seiten: **0px, 10px, 12px** - je nach Kachel. Bei 0px klebt die
+Ueberschrift an der ersten Zeile und liest sich als deren Beischrift.
+
+Der Rand sitzt jetzt an der Ueberschrift selbst, nicht am folgenden Element:
+
+    .tile > .label:first-child          { margin-bottom: 14px }
+    .ads-tile > .ads-eyebrow:first-child { margin-bottom: 14px }
+
+Drei Gruende fuer genau diese Bauweise:
+
+* `.tile`/`.ads-tile` sind normale Blockcontainer - benachbarte Raender fallen
+  zusammen. Vorhandene 10 oder 12px werden dadurch auf 14 **angehoben statt
+  addiert**. Ein `+ *`-Selektor haette sie addiert.
+* Absolut gesetzte Nachbarn (Zahnrad, Chevron) stehen nicht im Fluss und
+  bleiben unberuehrt. Ein `margin-top` auf ihnen haette das Zahnrad erneut aus
+  der Ecke geschoben - genau der Fehler aus Abschnitt CS.
+* `:first-child` trifft nur die Ueberschrift. `.label`/`.ads-eyebrow` tragen
+  auch Inhaltszeilen (die Anschrift des Autohauses), und die bleiben wie sie
+  sind - Entscheidung des Eigentuemers.
+
+Nachgemessen: alle Kachelkoepfe auf beiden Seiten bei 14px, Anschrift
+unveraendert 13px, Zahnrad weiter bei 8/8.
+
+### Einmalige Bereinigung des Profils
+
+Auf Wunsch des Eigentuemers entfernt `_profil_aufraeumen()` in `koordinator.py`
+ausgemusterte Profilfelder beim Start - Anlass ist
+`fahrzeug.hauptuntersuchung_faellig` aus Abschnitt CR. Ohne das bliebe der tote
+Schluessel fuer immer stehen: beide Oberflaechen lesen das Profil, aendern
+einzelne Felder und schreiben es vollstaendig zurueck, unbekannte Schluessel
+ueberleben das also.
+
+Geschrieben wird nur, wenn wirklich etwas wegfaellt. An der Testinstanz
+geprueft: Schluessel gesetzt, Neustart, Logzeile *"Ausgemusterte Profilfelder
+entfernt: fahrzeug.hauptuntersuchung_faellig"*, Schluessel weg - und beim
+zweiten Neustart keine Meldung und kein Schreibvorgang.
+
+Weitere ausgemusterte Felder gehoeren in `AUSGEMUSTERTE_PROFILFELDER`, nicht in
+neuen Sondercode.