Verschlafene Kilometer am Fahrtanfang zurueckholen

Der Dongle wacht nach dem Motorstart erst nach 28 s bis 19,5 min auf; was in
der Zeit gefahren wird, zeichnet er nicht auf. Die Kilometer holt das
Screening jetzt aus dem Endkilometerstand der Vorgaengerin zurueck und haelt
in luecke_km fest, wie viel davon betroffen ist.

Keine Sperre der GNSS-Verfeinerung, sondern eine Zerlegung: verschlafener
Anfang in ganzen Kilometern, aufgezeichneter Rest metergenau. Sonst waere die
feine Zahl systematisch zu klein und wuerde bei kleinen Luecken die Korrektur
stillschweigend wieder kassieren.

Zwei Schutzgitter, beide am Bestand gelernt: LUECKE_MAX_KM = 50 gegen
Differenzen, die keine Weckverzoegerung mehr sein koennen, und ein Rueckfall,
wenn _vollstaendig() die Werte daraufhin verwerfen wuerde.

Co-Authored-By: Claude Opus 5 <[email protected]>

AGENTS.md

@@ -12336,3 +12336,74 @@ wertlos; entweder auf `link.sheet` warten oder ein zweites Mal messen.
 Live geprüft (2026.9.6.1, beide Oberflächen): Reichweite 700, Nächster Service
 300, Kilometerstand 300, geladene Wide-Schnitte nur noch 300 und 700,
 Reservebalken `rgb(245, 5, 55)`.
+
+## DE. Verschlafene Kilometer zurückholen (2026.9.6.2)
+
+Der FMM003 kommt aus dem Deep Sleep nur über seinen Beschleunigungssensor hoch:
+die eingestellte Zündungsquelle ist die Motordrehzahl, die liegt am CAN, und
+CAN ist im Schlaf abgeschaltet. Gemessene Weckzeiten vom 18.08. bis 05.09.2026:
+**28 s bis 1170 s**. Am 05.09. fehlten dadurch **9 Minuten und 6 Kilometer** am
+Anfang der Rückfahrt — belegt am geräteeigenen GNSS-Wegzähler, der in fünf
+Stunden um 244 m weiterlief, während das Auto 6 km fuhr.
+
+Alle geräteseitigen Auswege sind vom Eigentümer geprüft und verworfen:
+Dauerbetrieb und GPS-Schlaf wegen des Ruhestroms, Periodic Wakeup ebenso, die
+Empfindlichkeit des Beschleunigungssensors ist am FMM003 nicht einstellbar, und
+die Bordspannung taugt an diesem Fahrzeug nicht als Zündungsquelle — bei
+laufendem Motor liegen **87,6 % von 2089 Messwerten** im Spannungsbereich des
+stehenden Wagens (Rekuperationsmanagement des RS 4).
+
+### Was jetzt passiert
+
+`verlauf.aufzeichnungsluecke_km()` — reine Funktion, sieben Tests in
+`tests/verlauf/test_aufzeichnungsluecke.py`. Zwischen zwei Fahrten steht das
+Fahrzeug; ist der Startkilometerstand trotzdem höher als der Endstand der
+Vorgängerin, wurden diese Kilometer gefahren, ohne dass ein Datensatz entstand.
+`screening._aufzeichnungsluecken_schliessen()` holt sie zurück und schreibt sie
+nach `luecke_km` (plus `luecke_unsicher`, wenn schon das Ende der Vorgängerin
+vorläufig war).
+
+**Keine Sperre der GNSS-Verfeinerung, sondern eine Zerlegung.** Der Eigentümer:
+„das macht die gesamte Nutzbarkeit des Fahrtenbuchs sehr grob". Richtig ist:
+
+```
+Strecke = verschlafener Anfang (ganze km, Tacho)
+        + aufgezeichneter Rest (metergenau, GNSS-Zähler)
+```
+
+Die Summe wird wie sonst gegen den Tacho geprüft. Die Unschärfe steckt damit
+nur im verschlafenen Stück; Fahrten ohne Lücke bleiben unverändert metergenau.
+Ohne die Zerlegung wäre die feine Zahl systematisch zu klein — und bei einer
+kleinen Lücke läge sie noch innerhalb von `GNSS_TOLERANZ_KM` und kassierte die
+Korrektur stillschweigend wieder ein. Genau dafür gibt es einen Test.
+
+### Zwei Schutzgitter, beide durch Schaden gelernt
+
+Der erste Lauf am 06.09.2026 griff sofort daneben und hat **drei Fahrten aus
+der Testphase beschädigt** (Kilometerstände auf `None`):
+
+* **`LUECKE_MAX_KM = 50.0`** — die längste gemessene Weckverzögerung sind
+  19,5 min, bei Autobahntempo rund 42 km. Ohne die Grenze fand die Regel
+  1078 km zwischen zwei Fahrten vom 27.08. (dort fehlen Fahrten in der Liste)
+  und 187831 km am 29.08. (Sprung zwischen den Zahlenbändern des Geräts).
+* **Rückfall, wenn `_vollstaendig()` die Werte verwirft.** Macht die Korrektur
+  die Strecke unplausibel, war die Annahme falsch, dass die beiden Fahrten
+  aufeinanderfolgen — dann bleibt der Bestand, wie er war.
+
+Die drei beschädigten Fahrten wurden aus `backups/20260901_072541/` von Hand
+wiederhergestellt. **Merkposten:** eine Regel, die rückwirkend auf den ganzen
+Bestand läuft, gehört vor dem ersten Lauf gegen den Bestand simuliert, nicht
+danach repariert.
+
+### Stand
+
+Live in `audi_ha_test`, 0 Tracebacks, 303 App-Tests grün. Die Rückfahrt vom
+05.09. steht jetzt mit **7,922 km statt ~1 km**, Zeile „Nicht aufgezeichnet:
+6 km am Anfang" in beiden Oberflächen (am gerenderten Panel nachgemessen).
+
+**Offen, im selben Zug gefunden:** dieselbe Fahrt hat ein **falsches Ende**.
+Das gepufferte Zündung-Aus kam am 06.09. um 14:28 mit Gerätezeit 23:21:29 an,
+`_echtes_ende()` hat daraus aber **14:27:25** gemacht — 15 h Dauer, 0,1 km/h
+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.