Das Ende einer verschlafenen Fahrt richtig bestimmen

Drei Fehler, die zusammen eine 5-Minuten-Fahrt als 15 Stunden mit 0,1 km/h
im Bestand stehen liessen:

- nach_neustart_fortsetzen() schloss eine laufende Fahrt bei ALLEM ausser
  "on" - auch bei Funkstille. Jetzt nur noch bei ausdruecklichem "off".
- _letztes_lebenszeichen() las nur die Zuendungsentitaet, die nur bei einem
  Wechsel schreibt. Zusaetzliche Quelle ist die Meldezeit-Entitaet, deren
  Werte die Geraetezeit jedes Datensatzes sind.
- Strecke und Dauer decken bei einer Luecke verschiedene Zeitraeume ab: der
  Durchschnitt entfaellt, und die Plausibilitaetspruefung rechnet ohne die
  verschlafenen Kilometer.

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

AGENTS.md

@@ -12407,3 +12407,55 @@ Das gepufferte Zündung-Aus kam am 06.09. um 14:28 mit Gerätezeit 23:21:29 an,
 Schnitt. Die Umstempelung auf Gerätezeit hat hier nicht gegriffen
 (`ZUORDNUNG_MAX_S = 1.0`). Das ist dieselbe Familie wie der Befund zu
 `_letztes_lebenszeichen()` und noch nicht behoben.
+
+## DF. Das Ende einer Fahrt, die das Gerät verschlafen hat (2026.9.6.3)
+
+Abschnitt DE hat die Kilometer gerettet, aber im selben Durchgang stand die
+Rückfahrt vom 05.09. mit **15 h 14 min Dauer und 0,1 km/h Schnitt** im
+Bestand. Drei Fehler, alle behoben.
+
+### 1. „Keine Meldung" ist kein „Zündung aus" — auch beim Neustart-Nachlauf
+
+`nach_neustart_fortsetzen()` prüfte `== "on"` und schloss bei **allem
+anderen** die laufende Fahrt — also auch bei `None`, `unavailable`,
+`unknown`. Genau die Regel, die `zuendung_geaendert()` seit jeher befolgt
+(„Funkstille ist keine Aussage"), fehlte hier. Steht die flespi-Anbindung beim
+Hochfahren noch nicht bereit, las die Funktion „nicht on" und beendete eine
+laufende Fahrt mit einem Ende aus `_letztes_lebenszeichen()` — im schlimmsten
+Fall „jetzt". Jetzt wird nur bei einem ausdrücklichen `"off"` geschlossen.
+
+### 2. Das letzte Lebenszeichen kam aus der falschen Entität
+
+`_letztes_lebenszeichen()` las nur den Verlauf der **Zündungsentität**. Die
+schreibt aber nur bei einem WECHSEL eine Zeile: bleibt die Zündung stundenlang
+an, ist ihr letzter Verlaufspunkt der Fahrtbeginn — und ein Ende daraus wäre
+eine Fahrtdauer von null. Am 06.09.2026 gemessen: die Fahrt vom Vorabend hatte
+seit 23:13:08 **genau drei Zeilen, alle aus derselben Sekunde**, obwohl das
+Gerät danach noch zwölf Minuten lang sendete.
+
+Zusätzliche Quelle ist jetzt die **Meldezeit-Entität** (`_meldezeiten()`): sie
+bekommt zu JEDEM Datensatz einen neuen Wert, und dieser Wert *ist* die
+Gerätezeit. Genommen wird das späteste Lebenszeichen aus beiden Quellen.
+
+### 3. Strecke und Dauer decken verschiedene Zeiträume ab
+
+Mit einer Lücke enthält `distance_km` die verschlafenen Kilometer, `duration_s`
+aber nicht — ihr Quotient ist bedeutungslos. Zwei Folgen:
+
+* **Der Durchschnitt entfällt.** Die Rückfahrt käme auf 92 km/h für eine
+  33-km/h-Fahrt. „Liegt nicht vor" ist die einzige ehrliche Angabe.
+* **Die Plausibilitätsprüfung in `_vollstaendig()` rechnet ohne die Lücke.**
+  Sonst verwirft eine Phantomgeschwindigkeit die Kilometerstände — am
+  06.09.2026 genau so passiert.
+
+### Stand
+
+Live in `audi_ha_test` am gerenderten Panel nachgemessen: *Startkilometer
+21.347 km · Endkilometer 21.355 km · Nicht aufgezeichnet 6 km am Anfang ·
+Dauer 5 Min. · Ø Geschwindigkeit liegt nicht vor.* Vorher: 15 h 14 min und
+0,1 km/h. 0 Tracebacks, 303 App-Tests und alle fünf Backend-Testdateien grün.
+
+**Was offen bleibt:** der Fahrtbeginn steht weiter dort, wo das Gerät aufwachte
+— neun Minuten und sechs Kilometer zu spät. Ihn aus der Motorlaufzeit
+zurückzurechnen hat der Eigentümer abgelehnt, solange es eine gerechnete statt
+gemeldete Zahl wäre.