Meldezeit auch nach hinten prüfen - "Geparkt seit 20698 Tg." war die Unix-Epoche

geraetezeit() prüfte nur, ob die Meldezeit in der Zukunft liegt. Ein Sensor,
der 0 meldet, rutschte durch, und fromtimestamp(0) ergibt 1970 - auf der realen
Instanz sichtbar als "Geparkt seit 20698 Tg. 9 Std. 39 Min.".

Neu geraetezeit_plausibel(): nicht aus der Zukunft und nicht älter als
MELDEZEIT_RUECKLAUF (365 Tage). Geprüft wird an drei Stellen - beim Auslesen
der Gerätezeit, beim Setzen des Parkbeginns und beim LADEN aus dem
Laufzeit-Store, denn ein einmal falsch gespeicherter Wert überlebt sonst jedes
Update.

Fängt auch eine im Setup falsch zugeordnete ID-Entität ab: das flespi-Gerät hat
drei ID-Sensoren, deren Namen dem Zeitstempel ähneln, und deren Werte ergeben
als Unix-Zeit ebenfalls 1970.

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

AGENTS.md

@@ -1,7 +1,7 @@
 # AGENTS.md — Project state, review findings, open items, and working rules
 
 **Last updated: 2026-09-02** (Null heisst unbekannt, Momentanwerte nur fuer
-"jetzt", Uebersicht-Symbol vergroessert, `2026.9.2.5`, Abschnitt BN.
+"jetzt", Uebersicht-Symbol vergroessert, `2026.9.2.7`, Abschnitte BN und BO.
 Davor: Verbrauchsfaktor aus dem Tankbeleg, `2026.9.1.32`,
 Abschnitt BM. Davor: Reifenzaehler ohne Fahrzeugwechsel, „Raeder“
 statt „Reifen“, `2026.9.1.29`, Abschnitt BL. Davor: Ortsnamen aus dem Backend, Verbrauchseichung an
@@ -7554,6 +7554,56 @@ halb so hoch wie breit. Echte Hoehengleichheit mit den Nachbarn gibt es nur
 durch Neuzeichnen des Bogens mit groesserem Winkel - dem Eigentuemer angeboten,
 nicht unaufgefordert gemacht.
 
+## BO. "Geparkt seit 20698 Tg." - die Meldezeit war nur nach vorn geprueft (2026.9.2.7)
+
+Gemeldet von der realen Instanz. Nachgerechnet: 20698 Tage und 9:39 vor dem
+Ablesezeitpunkt ergeben den Sekundenwert **0** - die Unix-Epoche.
+
+`geraetezeit()` prueft seit Abschnitt AY, ob die Meldezeit in der ZUKUNFT
+liegt (falsch gestellte Geraeteuhr). Nach hinten gab es keine Grenze. Ein
+Sensor, der 0 meldet, rutschte damit ungehindert durch, und
+`fromtimestamp(0)` ergibt 1970.
+
+### Warum "der Dongle liefert nicht" die falsche Erklaerung war
+
+Auf die Rueckfrage des Eigentuemers nachgesehen: im Testcontainer steht
+`message_timestamp` auf 1788342429, also exakt jetzt. Beide Instanzen haengen
+an derselben flespi-Quelle - am Geraet kann es also nicht liegen.
+
+Die wahrscheinlichere Ursache ist die Zuordnung. Das flespi-Geraet hat FUENF
+aehnlich klingende Sensoren, aber nur zwei sind Zeitstempel:
+
+| Entitaet | Wert | tauglich |
+|---|---|---|
+| `…_message_timestamp` | 1788342429 | **ja - die richtige** |
+| `…_timestamp_when_server_received_a_message` | 1788342433 | nein, Ankunftszeit |
+| `…_id_of_channel_that_received_a_message` | 1421491 | nein, eine ID |
+| `…_id_of_device_that_received_a_message` | 8767678 | nein, eine ID |
+| `…_id_of_device_type_of_device…` | 1304 | nein, eine ID |
+
+Eine faelschlich zugeordnete ID ergibt als Unix-Zeit ebenfalls einen Zeitpunkt
+kurz nach 1970 - dieselbe Anzeige, andere Ursache. Beim Eigentuemer noch
+offen, welcher der beiden Faelle vorliegt.
+
+### Der Riegel sitzt an drei Stellen, nicht an einer
+
+1. `geraetezeit_plausibel()` (neu in `verlauf.py`): nicht aus der Zukunft
+   (`MELDEZEIT_VORLAUF`, 5 min) und nicht aelter als `MELDEZEIT_RUECKLAUF`.
+2. `geparkt_seit_setzen()` prueft mit - so kommt ein solcher Wert gar nicht
+   erst in den Laufzeit-Store.
+3. **Beim LADEN**, und das ist der Teil, der die reale Instanz betrifft: der
+   bereits gespeicherte Epochenwert haette jedes Update ueberlebt. Geprueft
+   wurde dort nur, ob sich das Datum lesen laesst, und
+   `_parkbeginn_nachholen()` springt nicht ein, solange etwas gespeichert ist.
+
+`MELDEZEIT_RUECKLAUF = 365 Tage` (Vorgabe des Eigentuemers, zuerst 30). Sehr
+weit gefasst und genau deshalb ungefaehrlich: das Geraet puffert real nur
+Stunden bis Tage, die Grenze kann also keine echte gepufferte Meldung
+verwerfen - was sie fangen soll, liegt Jahrzehnte daneben.
+
+An acht Faellen geprueft: Epoche, beide ID-Verwechslungen und 366 Tage
+verworfen; jetzt, 2 Tage und 364 Tage angenommen.
+
 ## Working conventions (observed — keep them)
 
 - German is the project language: identifiers, comments, commits, UI texts. Exceptions: