Say how far the next service is, not only how long

The service badge has always watched two triggers - the next-due date and the
next-due odometer reading - and shown one of them. It ranked the two and
printed the worse one's sentence, so a car comfortable on both read "OK ·
354d" and never said that the odometer target was 13.612 km away, even though
the Information card right under it prints the 15.000 km the badge is
counting towards. Whichever trigger arrives first ends the interval, so
naming only one of them describes half the thing.

Both are named now. With both signals known the label is a severity headline
followed by each trigger as a bare quantity - "OK · 354d · 13.612 km", "Due
in 12d · 13.612 km" - which is the shape reminderStatus in the same file
already uses, it having had the two-trigger problem first. The signals gained
the number behind their own wording to make that possible; they were
returning only a formatted sentence.

Wording is unchanged wherever only one signal has data, which is the case
this rewrite most risked disturbing: a car with no odometer target still
reads "OK · 354d" exactly as before, one with no service date still reads
"13.612 km left", and neither still reads "No data". The new keys are only
reached when there are genuinely two numbers to print.

An overdue badge lists only the triggers that have actually passed. "Service
Overdue 30d · 13.612 km" would read as overdue by 13.612 km, which is the
opposite of what that number means, so the trigger that is still comfortable
stays out of a sentence headed "Overdue". It costs the remaining distance on
a date-overdue badge; the alternative costs the reader's trust in the number.

The phone carried a line-for-line copy of this logic and gets the same
treatment rather than being left a version behind - the two would otherwise
disagree about the same car on the same day. Its signals become a private
record type, since Status is public and shared with the expiry, reminder and
warranty badges that have no second trigger and no use for the field.

Two new keys (status.okIn, status.serviceOverdueBy) in all three languages in
both apps. The day and km fragments they interpolate were already translated
for the reminder badge, so the parts assemble in Polish and Danish without
new wording: "OK · 354 dni · 13 612 km", "OK · 354 d · 13.612 km", each with
its own grouping separator.

Verified by flutter analyze (clean), flutter test - 21 pass, including the
key-parity test that would have caught a key added in English alone - and npm
run build for the web. The web function was driven through the real module in
a browser over ten cases: both signals known at each severity, each of the
two overdue alone, both overdue together, either signal missing, neither, and
a zero-odometer car, in all three languages.

Not verified: no new automated test covers this. The web app has no test
runner and the phone's format tests cover the catalogue lookups rather than
the badge, so the ten cases above were checked by hand and are not guarded
against the next edit. The deployed Web App still serves the previous build
and will keep reading "OK · 354d" until it is redeployed.

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

Phone App/assets/i18n/pl.json

@@ -329,8 +329,10 @@
     "serviceOverdueDays": "Serwis zaległy {days} dni",
     "dueInDays": "Termin za {days} dni",
     "okDays": "OK · {days} dni",
+    "okIn": "OK · {parts}",
     "noKm": "Brak przebiegu",
     "serviceOverdueKm": "Serwis zaległy {km} km",
+    "serviceOverdueBy": "Serwis zaległy {parts}",
     "inKm": "Za {km} km",
     "kmLeft": "Pozostało {km} km",
     "expiredAgo": "Wygasło {days} dni temu",