Ölwechsel/Inspektion-Anzeige repariert, Selbst-Update der Integration gebaut

Zwei getrennte Themen in einem Commit, beide in derselben Sitzung entstanden:

1. Ölwechsel/Inspektion wurden komplett ausgeblendet ("kein Eintrag im
   Servicebuch"), sobald kein Servicebucheintrag vorlag - selbst wenn der
   zugeordnete Sensor eine gültige Fälligkeit meldete. In beiden Frontends
   prüfte die Anzeige nur den Servicebuch-Zweig, bevor sie die
   Fahrzeugmeldung überhaupt las. Jetzt steht die Fahrzeugmeldung für sich;
   fehlt zusätzlich ein Servicebucheintrag, übernimmt eine neue,
   fahrtenlog-basierte Prognose (kmProTagAusFahrten()/meldungsPrognose())
   die Hochrechnung statt der Servicebuch-Rate - deckelt auf die vom
   Fahrzeug selbst gemeldete Zeitgrenze, falls zu wenig gefahren wird.

2. install.ps1 als Update-Weg wird von Windows Smart App Control blockiert,
   ohne Umgehungsmöglichkeit. Die Integration lädt sich jetzt auf
   Tastendruck selbst von Gitea (aktualisierung.py), verifiziert das
   Manifest vor jedem Tausch und tauscht per os.rename mit automatischem
   Rollback bei Fehlern - install.ps1 bleibt nur noch für die
   Erstinstallation nötig. Zugangstoken über einen neuen OptionsFlow in
   entry.options, nie in configuration.yaml.

Nebenbei: mehrere seit der HACS-Ausschluss-Entscheidung liegen gebliebene
falsche HACS-Referenzen in Code-Kommentaren und einem UI-Text korrigiert.

Details, Sicherheitsbegründung und Verifikationsstand in AGENTS.md,
Abschnitte I und J.

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

companion-app/src/api/index.ts

@@ -197,6 +197,26 @@ export class DataMetricApi {
     }
   }
 
+  /* ------------------------------------------------- Selbst-Update der
+     Integration (aktualisierung.py) - Ersatz für install.ps1, das Windows
+     Smart App Control blockiert. Bewusst NICHT über die Warteschlange, wie
+     historieImportieren() oben: beides sind ausdrückliche, sofortige
+     Aktionen, kein Zustand, den man im Funkloch absetzt und später
+     nachgeholt haben will. Ergebnis kommt über
+     appVersionAngabeLesen()/daten.integration_update zurück, nicht über den
+     Rückgabewert dieser Aufrufe. */
+
+  /** Fragt nur nach, ob eine neuere Fassung vorliegt - lädt nichts herunter. */
+  updatePruefen(): Promise<unknown> {
+    return this.rest.dienstAufrufen(DIENST_DOMAIN, "update_pruefen");
+  }
+
+  /** Lädt die neueste Fassung und ersetzt den Integrationsordner. Home
+      Assistant muss danach neu gestartet werden. */
+  updateInstallieren(): Promise<unknown> {
+    return this.rest.dienstAufrufen(DIENST_DOMAIN, "update_installieren");
+  }
+
   /* ------------------------------------------- Import aus dem HA-Verlauf
      Bewusst NICHT über die Warteschlange, anders als die übrigen
      schreibenden Vorgänge: der Import ist keine Eingabe, die man im Funkloch

companion-app/src/api/types.ts

@@ -172,10 +172,26 @@ export interface Buendelangabe {
   url: string;
 }
 
+/** Ergebnis der letzten "Auf Update prüfen"/"Update installieren"-Aktion
+    (custom_components/audi_dashboard/aktualisierung.py, dienste.py). `null`,
+    solange noch nie geprüft wurde - ein normaler Zustand, kein Fehler.
+    Ersetzt install.ps1 als Update-Weg, weil Windows Smart App Control es
+    zuverlässig blockiert. */
+export interface IntegrationUpdateAngabe {
+  verfuegbar: boolean;
+  version: string | null;
+  geprueft_am: string;
+  /** true unmittelbar nach einer erfolgreichen Installation - dann ist ein
+      Neustart von Home Assistant nötig, damit die neue Fassung geladen wird. */
+  installiert: boolean;
+  fehler: string | null;
+}
+
 /** Nutzlast von sensor.audi_dashboard_app_version. */
 export interface AppVersionAngabe {
   app: string | null;
   buendel: Buendelangabe | null;
+  integration_update: IntegrationUpdateAngabe | null;
 }
 
 /* -------------------------------------------------- Entitäts-Verzeichnis */