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.

AGENTS.md

@@ -91,14 +91,16 @@ Root files: `dashboard-muster*.html` = original static prototype (superseded, re
 `bauauftrag.md`/`.html` = original build brief (historical), `DESIGN_BRIEF_DATAMETRIC360.md` = the
 prompt for the Claude Design project.
 
-**`homeassistant/` in one paragraph:** 10 pyscript scripts + 4 modules (`pyscript/modules/`); trip
-detection via the iPhone WLAN sensor with pause tolerance, two-stage trip completion via HA history
-screening (odometer often updates only on the next trip), fill-up detection on fuel-level rise,
-Shell PDF parser (`data/shell_beleg_parser.py`, subprocess, the only tested part of the repo), tire
-km counter, backup, self-update, image management. Frontend: one file `www/audi-dashboard-app.js`
-(3,130 lines, custom element, no framework/bundler), 5 tabs + ~19 detail routes, cache-busting via
-`audi-dashboard-version.json` + loader stub. Entity IDs configured centrally in
-`pyscript/modules/einstellungen.py` (the one file edited before install). Deploy: `update.ps1`
+**`homeassistant/` in one paragraph:** 10 pyscript scripts + 5 modules (`pyscript/modules/`); trip
+detection via the FMM003 ignition sensor with pause tolerance (the iPhone WLAN sensor is gone — see
+section B), two-stage trip completion via HA history screening (odometer often updates only on the
+next trip), fill-up detection on fuel-level rise, Shell PDF parser (`data/shell_beleg_parser.py`,
+subprocess, the only tested part of the repo), tire km counter, backup, self-update, image
+management. Frontend: one file `www/audi-dashboard-app.js`
+(~4,000 lines, custom element, no framework/bundler), 5 tabs + ~19 detail routes, cache-busting via
+`audi-dashboard-version.json` + loader stub. Entity IDs are assigned **in the UI** (Settings →
+Fahrzeug einrichten → Setup), stored as overrides in `data/entitaeten.json`;
+`pyscript/modules/einstellungen.py` holds only the built-in defaults. Deploy: `update.ps1`
 (robocopy to Samba share) or — still inactive — self-update from git.
 
 **`companion-app/` — what exists:** dependency-free, strictly typed TS data layer (`src/api/`):
@@ -111,8 +113,10 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac
 **DataMetric360 architecture (short — details in `COMPANION_APP_ARCHITECTURE.md`):**
 - Future data source: **Teltonika FMM003** on the CAN bus, fully replacing the iPhone WLAN sensor
   and the VAG integration.
-- **Current data path (since 2026-08-11): Codec JSON → MQTT/TLS → Mosquitto add-on → HA.** Traccar
-  is **dropped** (the decision log deliberately remains in the architecture doc, marked ÜBERHOLT).
+- **Current data path (since 2026-08-12): FMM003 → flespi (native Codec8/TCP, IMEI auth) → HA.**
+  Both earlier directions are dropped: Traccar first, then the self-hosted MQTT/TLS broker — the
+  router's port-forward turned out to be unusable. The decision logs deliberately remain in the
+  architecture doc, marked ÜBERHOLT. Details and open steps in section B below.
 - Frontend access: HA REST + WebSocket with a long-lived access token (no `hass` object).
 - External access: Cloudflare Tunnel + reverse proxy with a path allowlist; HA itself stays
   unreachable. Domain **`datametric360.app`** registered (all-inkl, 2026-08-11).
@@ -317,9 +321,9 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac
       Parkplatz" state, fuel/range, and Route (Google Maps deep link) / Teilen (Web Share API)
       actions. Backend: new `STANDORT_TRACKER` entity-ID setting in `einstellungen.py` (device_
       tracker with lat/lon attributes), published via a new `_standort()` helper in
-      `frontend_veroeffentlichung.py` — **left empty/unconfigured**, no live vehicle GPS source
-      exists yet (same FMM003/flespi gap as section B); the tile shows "Kein GPS-Signal vom
-      Fahrzeug" until that's wired up. Verified end-to-end in `audi_ha_test` with a manually
+      `frontend_veroeffentlichung.py`. The built-in default points at the author's test device
+      (`device_tracker.testzone_fmm003`); until the FMM003 actually delivers positions (section B),
+      that entity does not exist and the tile shows "Kein GPS-Signal vom Fahrzeug". Verified end-to-end in `audi_ha_test` with a manually
       created `device_tracker.test_fahrzeug` test entity (tile, fullscreen map, and menu all
       confirmed rendering/populating correctly); the device's own location (browser Geolocation
       API) and the Route/Teilen deep links work independently of the vehicle-GPS gap. Pushed to