Setup-Menue: Sensorkennung per naechstem Verwandten statt globalem Praefix

Zwei weitere Korrekturrunden, beide vom Nutzer live erkannt:

- .6: paarweise Abstimmung statt fortlaufender Verengung - robuster gegen
  einen einzelnen Ausreisser, aber grundsaetzlich noch falsch.
- .7: die eigentliche Ursache war, dass diese Installation zwei etwa
  gleich grosse Sensorquellen gleichzeitig hat (9 FMM003-Rollen, 18 Rollen
  einer zweiten Integration mit "audi_rs_4_avant_"-Praefix) - ein
  EINZELNES globales "Sieger"-Praefix kann immer nur eine der beiden
  Quellen richtig kuerzen. entitaetIdKurz() sucht jetzt pro Feld den
  naechsten Verwandten unter allen zugeordneten Sensoren und kuerzt nur
  dessen gemeinsames Praefix - unabhaengig von Anzahl und Groesse der
  Quellen.

Diesmal vor dem Deploy anhand der ECHTEN sensor.audi_dashboard_entitaeten-
Zuordnung durchgerechnet statt mit erfundenen Test-IDs (das hatte den
.6-Fehler faelschlich als behoben erscheinen lassen). Version 2026.8.28.7,
live verifiziert: alle 20 Einzelwert-Felder zeigen die richtige, kurze
Kennung, keine installationsspezifischen Reste aus beiden Quellen mehr.

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

AGENTS.md

@@ -4241,6 +4241,46 @@ plus the `TANK_DISTANZ_SENSOR` fallback case above and a screenshot confirming t
 --check` clean at each step, manifest bumped `2026.8.28.4` → `.5`, `audi_ha_test` restarted and confirmed
 clean via log both times.
 
+**`.5`'s own verification above was itself misleading - the owner caught the real bug immediately after
+("I still see testcar_b9_fmm003_testintegratoin_ and audi_rs_4_avant_").** `.5`'s `setupGemeinsamesPraefix()`
+computed ONE global prefix by intersecting every mapped sensor's ID down to their shared characters - and a
+single outlier (any one field mapped to a sensor from a different source than the rest) collapses that
+intersection to nothing, so EVERY field falls back to its full, unstripped ID. The live verification quoted
+above only exercised four fields and happened not to include the one that broke it - a real gap in how
+thoroughly that pass was checked, not a fluke in the code.
+
+Fixed properly in `.6`: replaced the single global intersection with pairwise voting (every sensor pair's own
+common prefix, the most frequently occurring one wins) - more robust against one outlier, but **still wrong
+for a different reason**, found by the owner's report and confirmed by pulling the actual live
+`sensor.audi_dashboard_entitaeten` data (not by re-reading the source - the only way this surfaced): this
+installation genuinely has **two comparably-sized sensor sources at once** - 9 FMM003-sourced roles
+(ignition, odometer, tank, battery, GPS) and 18 roles from a second integration, prefixed
+`audi_rs_4_avant_` (all four doors, all four windows, tailgate/hood/lock/sunroof/light, all four service-date
+fields). A single global "winner" prefix, however it's computed, can only ever strip ONE of the two families
+correctly and leaves the other's IDs fully unstripped - exactly what both `.5` and `.6` did, just for
+different roles each time.
+
+**`.7` drops the idea of a single global prefix entirely.** `entitaetIdKurz()` now finds, for the entity
+being displayed, its own single closest relative among every other currently-mapped sensor (the one it
+shares the longest prefix with) and strips only that pairwise prefix - computed independently per field, so
+it doesn't matter how many different sensor sources are mixed together or how large each cluster is. Verified
+by pulling the *actual* stored `werte` mapping from `sensor.audi_dashboard_entitaeten` (not fabricated test
+IDs like the `.5`/`.6` passes used) and running the real algorithm against it before deploying - this is what
+caught the `.6` design flaw *before* declaring it fixed, rather than after another owner report. A pleasant
+side effect: `NAECHSTER_OELWECHSEL_SENSOR`/`NAECHSTE_INSPEKTION_SENSOR` (`oil_change_due`/`inspection_due`)
+and their `_STRECKE_SENSOR` counterparts (`oil_change_distance`/`inspection_distance`) now pair off with each
+other specifically and reduce to `"due"`/`"distance"` - each field lands next to its true sibling, not just
+"some" shared prefix.
+
+Verified live in `audi_ha_test` at every step (`.6` then `.7`), each time reading the actual rendered Setup
+popup fresh after a real restart (not a stale tab - confirmed via `performance.getEntriesByType('resource')`
+showing the new `?v=` served with a nonzero transfer size each time). Final state (`.7`), all 20 single-value
+fields checked in one pass: every FMM003 role shows its bare signal name
+(`external_power_voltage`, `can_ambient_air_temperature`, ...), every `audi_rs_4_avant_` role shows its own
+(`tailgate`, `hood`, `sunroof`, `parking_lights`, `due`, `distance`, ...), nothing shows installation noise
+from either source. `node --check` clean at each step. Manifest `2026.8.28.5` → `.6` → `.7`, `audi_ha_test`
+restarted and confirmed clean via log each time.
+
 ---
 
 ## Working conventions (observed — keep them)