Kleinere Befunde und Dokumentation aus dem Review

Frontend, kleinere Befunde:
- Das Standort-Menue liess sich nur wischen oder ueber den Kartenmarker
  oeffnen. Der Griff ist jetzt ein Knopf mit aria-expanded, damit auch per
  Tastatur erreichbar; der Umschalter Strasse/Satellit hat aria-pressed und
  ein Label, das den Zustand nennt.
- Der Filterschalter "Nur passende Sensoren anzeigen" wirkte nicht, solange
  eine Auswahlliste offen war: der Klick-Handler ersetzte das Overlay-DOM,
  bevor das change-Ereignis des Kontrollkaestchens ausgeliefert wurde. Er
  wird jetzt vor dem Schliessen der Liste behandelt.
- Der Theme-Wechsel zeichnete nicht neu, die Leaflet-Kacheln blieben bis zum
  naechsten Backend-Update im alten Stil - seit der Dauerkarte auf der
  Uebersicht deutlich sichtbar.
- Toter Code entfernt (fahrzeugGlyphPfade, .dot.neutral) und zwei Kommentare
  berichtigt, die Gegenteiliges behaupteten.

Dokumentation:
- AGENTS.md widersprach sich an sechs Stellen. Berichtigt: Fahrterkennung
  laeuft ueber die Zuendung, nicht ueber WLAN; Datenweg ist flespi, nicht
  MQTT; Modulzahl und Zeilenzahl stimmen wieder; Entity-IDs werden im
  Setup-Menue zugeordnet, nicht in einstellungen.py; STANDORT_TRACKER ist
  belegt, nicht leer.
- SPECIFICATION.md beschreibt durchgehend den Stand vor der FMM003-
  Umstellung. Statt es zu Teilen umzuschreiben und dabei Ungenauigkeiten zu
  riskieren, steht jetzt ein datierter Hinweis am Anfang, der die drei
  geaenderten Punkte benennt und auf AGENTS.md verweist. Alles Uebrige des
  Dokuments gilt unveraendert weiter.
- INSTALL.md: Die zirkulaere Schrittfolge (Schritt 4 verweist auf 9, Schritt
  7 auf 4) ist als solche benannt und aufgeloest. Die Override-Datei ist mit
  Pfad genannt, samt dem Hinweis, dass sie gesichert wird. Und die drei mit
  Test-Entitaeten der Entwicklungsinstanz vorbelegten Rollen sind erwaehnt -
  auf einer frischen Installation zeigen sie ins Leere.
- README, Profilvorlage: WLAN-Reste entfernt, zwei Falschaussagen aus dem
  ersten Review nachgezogen (Statistik rechnet echt, die
  97-Prozent-Volltankungsregel wurde entfernt), Dateiuebersicht um die
  fuenf fehlenden pyscript-Dateien und entitaeten.py ergaenzt.
- update.ps1 liefert jetzt auch shell_beleg_parser.py aus. Die Datei liegt in
  data/, ist aber Code - Aenderungen am Belegleser, dem einzigen getesteten
  Teil des Projekts, kamen bisher auf keiner Instanz an.
- design/README: Zwei Dateien der Inhaltstabelle liegen gar nicht in dem
  Ordner, weshalb das Board aus der Repo-Kopie heraus leer bleibt - jetzt
  vermerkt. Ausserdem die Behauptung berichtigt, die Auflage ruehre
  audi-dashboard-app.js nicht an: der Stylesheet-Loader wurde dort ergaenzt.

Geprueft: Panel laedt, alle neun pyscript-Entitaeten werden veroeffentlicht,
Zuordnen und Zuruecksetzen funktionieren, keine neuen Fehler im Protokoll.

homeassistant/INSTALL.md

@@ -93,8 +93,13 @@ Anders als früher wird dafür **nicht** mehr `pyscript/modules/
 einstellungen.py` von Hand bearbeitet — das übernimmt ein grafisches
 Setup-Menü direkt in der App: **Mein Audi → Einstellungen → Fahrzeug
 einrichten → Einrichten → „Setup — Sensoren zuordnen"** (letzter Punkt,
-erscheint erst nach Klick auf „Einrichten"). Dafür muss die App bereits
-laufen, siehe Schritt 9 zuerst.
+erscheint erst nach Klick auf „Einrichten").
+
+> **Reihenfolge beachten:** Dieser Schritt braucht eine bereits laufende App.
+> Arbeite deshalb erst die Schritte 5 bis 9 ab (Token, Neustart, Prüfung,
+> Restarbeiten, Frontend) und komm dann hierher zurück. Schritt 7 verweist
+> seinerseits auf die hier vorgenommene Zuordnung — das ist kein Widerspruch,
+> sondern schlicht die Reihenfolge: erst starten, dann zuordnen, dann prüfen.
 
 Das Setup-Menü listet jede Sensor-Rolle, die die App kennt (Zündung/
 Fahrterkennung, Kilometerstand, Tankfüllstand, Standort, Batteriespannung,
@@ -104,6 +109,16 @@ anzeigen" grenzt auf die erwartete Domäne/Einheit ein) und schreibt die
 Auswahl direkt in eine Override-Datei — `einstellungen.py` selbst bleibt
 unverändert.
 
+Die Override-Datei ist `/config/audi_dashboard/entitaeten.json`. Sie wird von
+der automatischen Sicherung und vom Backup-Export mit erfasst; ein
+Wiederherstellen spielt die Zuordnung also mit zurück.
+
+**Hinweis zu den Vorgabewerten:** Drei Rollen sind in `einstellungen.py` mit
+den Test-Entitäten der Entwicklungsinstanz vorbelegt (Zündung, Batterie-
+spannung, Standort — jeweils `*_testzone_fmm003`). Auf einer frischen
+Installation zeigen sie ins Leere; das Setup-Menü meldet dann „Entität nicht
+gefunden". Einfach die eigenen Entitäten zuordnen, damit ist es erledigt.
+
 **Zwingend, damit die Fahrterkennung läuft:**
 - **Zündung/ACC-Status** (`ZUENDUNG_SENSOR`) — ein `binary_sensor`, `on`
   = Fahrt läuft. Kommt vom Teltonika FMM003 (z. B.
@@ -226,8 +241,9 @@ Der `panel_custom`-Eintrag aus Schritt 3 zeigt auf
   Prototyp. Das Gerät braucht dafür zusätzlich zur Tailscale-Verbindung
   normalen Internetzugang — sonst bleibt die Karte auf der Fahrt- und
   Tankvorgang-Detailseite leer.
-- **Statistik-Seite** zeigt weiterhin Beispielzahlen aus dem Prototyp,
-  keine echte Auswertung der eigenen Fahrten — eigenes Arbeitspaket.
+- **Statistik-Seite** wertet die eigenen Fahrten und Tankvorgänge echt aus
+  (Zeiträume, Verbrauch, Tag/Nacht, privat/Arbeitsweg). Sie bleibt nur so
+  lange leer, wie noch keine Fahrten und Tankungen erfasst sind.
 
 ## Schritt 10 — künftige Updates einspielen, ohne die App neu zu bauen