Endpunkt-Status-Icon mit Ereignis-Log und Update-Erkennung ergaenzen

Ein neues Status-Icon im Titelbalken zeigt den Zustand der lokalen
Transkripte und der Serverabfrage; ein Klick oeffnet ein eigenes Fenster
mit persistiertem, zeitgestempeltem Ereignis-/Fehlerprotokoll (loeschbar).
Ausserdem erkennt die App beim Start Erstinstallation vs. Update
(plattformunabhaengig fuer Windows und Linux) und meldet Updates per
nativer Benachrichtigung.

Dazu: Versionierungs-Policy dokumentiert (package.json vor jedem Release
erhoehen, sonst greift weder die Update-Erkennung noch bleiben alte
Release-Dateien in release/ erhalten), sowie zwei neue Dokumente fuer
Endanwender (BENUTZERHANDBUCH.md) und eine Download-Webseite
(PRODUKTSEITE.md).

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

README.md

@@ -73,6 +73,7 @@ ELECTRON_OZONE_PLATFORM_HINT=wayland ./start.sh   # nativ Wayland, ohne Position
 | Aktion | Wirkung |
 |---|---|
 | Kopfzeile ziehen | Fenster verschieben (Position wird gemerkt) |
+| Statuspunkt (links vom Zahnrad) | Fehler-/Ereignis-Log öffnen |
 | ⚙ | Einstellungen öffnen |
 | „Details“ | Modell-Aufschlüsselung, Tempo und Datengrundlage aufklappen |
 | `–` | Ausblenden — Rückkehr über das Tray-Symbol |
@@ -98,6 +99,23 @@ sofort beim Umschalten übernommen, unabhängig vom Speichern.
 dann über der Arbeit, ohne sie zu behindern. Zurückschalten geht über das
 Tray-Menü.
 
+### Endpunkt-Status & Ereignis-Log
+
+Der Punkt links vom Zahnrad zeigt den Zustand der beiden Datenquellen —
+Symbol *und* Farbe, nie Farbe allein:
+
+| Zustand | Bedeutung |
+|---|---|
+| ● grün | Beide Quellen funktionieren |
+| ◆ gelb | Serverabfrage gestört (App rechnet lokal weiter) |
+| ◆ rot | Lokale Transkripte nicht lesbar — die Kerndatenquelle fehlt |
+
+Ein Klick öffnet ein eigenes Fenster mit dem chronologischen, zeitgestempelten
+Protokoll aller Störungen (Lesefehler, Dateiüberwachung, Serverabfrage) sowie
+App-Ereignissen wie Erstinstallation und Updates. Das Protokoll übersteht
+Neustarts und das Speichern der Einstellungen — es liegt in `state.json` — und
+lässt sich über „Log löschen“ im selben Fenster zurücksetzen.
+
 ## Was angezeigt wird
 
 **Laufende Sitzung** — Auslastung des aktuellen 5-Stunden-Fensters, dazu
@@ -206,8 +224,10 @@ src/main/paths.js        Speicherorte für Konfiguration und Zustand
 src/main/autostart.js    Anmeldestart je Betriebssystem
 src/preload.js           contextBridge fürs Widget
 src/settings-preload.js  contextBridge für den Einstellungsdialog
+src/errors-preload.js    contextBridge fürs Fehler-/Ereignis-Log
 src/renderer/            Widget-Oberfläche
 src/settings/            Einstellungsdialog
+src/errors/              Fehler-/Ereignis-Log-Fenster
 ```
 
 Alle Dateizugriffe und Rechnungen passieren im Main-Prozess; der Renderer
@@ -223,11 +243,41 @@ Zwei Details, die nicht offensichtlich sind:
   Retries und beim Kompaktieren mehrfach ins Transkript; ohne Dedup über
   `message.id` wären alle Zahlen zu hoch.
 
+## Version & Updates
+
+Die App erkennt beim Start selbst, ob es sich um eine Erstinstallation oder
+ein Update handelt: Sie vergleicht `app.getVersion()` (aus `package.json`,
+plattformunabhängig für Windows und Linux) mit der zuletzt in `state.json`
+gemerkten Version. Bei einer neuen Version erscheint einmalig eine native
+Systembenachrichtigung, und das Ereignis landet zeitgestempelt im
+Fehler-/Ereignis-Log (siehe oben). Bestehende Konfiguration und Kalibrierung
+bleiben davon unberührt — geschrieben wird ausschließlich das eine Feld
+`state.json:appVersion`.
+
+**Voraussetzung dafür ist eine bei jedem Release erhöhte Versionsnummer.**
+Vor jedem Build deshalb zuerst `version` in `package.json` erhöhen (SemVer:
+`1.1.0` → `1.2.0` für neue Funktionen, `1.1.1` für Fehlerbehebungen). Ohne
+diesen Schritt erkennt die App den neuen Build nicht als Update, und der
+Installer überschreibt in `release/` stillschweigend die Datei der
+vorherigen Version, weil deren Name (`artifactName`) die Versionsnummer
+enthält:
+
+```powershell
+npm version minor    # oder: patch / major — schreibt package.json, kein Tag/Commit nötig
+npm run dist
+```
+
+`npm version` legt standardmäßig auch einen Git-Commit und -Tag an; ohne das
+genügt es, `version` in `package.json` von Hand zu ändern.
+
 ## Release bauen
 
 Gebaut wird jeweils auf dem Zielsystem — electron-builder kann `.deb` nicht
 sinnvoll von Windows aus erzeugen und umgekehrt keine signierten `.exe` unter
-Linux.
+Linux. Beide Linux-Ziele (`AppImage`, `.deb`) brauchen zudem Linux-eigene
+Werkzeuge (`mksquashfs` bzw. `fpm`) und lassen sich nicht unter Windows
+erzeugen, auch nicht über WSL ohne eine dort eingerichtete Node.js- bzw.
+Ruby-Umgebung.
 
 ### Windows
 
@@ -236,12 +286,12 @@ npm run dist    # Installer + portable Fassung nach release/
 npm run pack    # nur entpackt nach release/win-unpacked (schneller Test)
 ```
 
-Ergebnis in `release/`:
+Ergebnis in `release/` (Version aus `package.json`, siehe oben):
 
 | Datei | Zweck |
 |---|---|
-| `Claude Live Dashboard-1.0.0-x64.exe` | NSIS-Installer, ~97 MB |
-| `Claude Live Dashboard-1.0.0-portable.exe` | läuft ohne Installation |
+| `Claude Live Dashboard-<version>-x64.exe` | NSIS-Installer, ~97 MB |
+| `Claude Live Dashboard-<version>-portable.exe` | läuft ohne Installation |
 
 Der Installer läuft **ohne Administratorrechte** (`perMachine: false`),
 installiert also ins Benutzerprofil. Zielverzeichnis ist wählbar, Desktop- und
@@ -265,8 +315,8 @@ Ergebnis in `release/`:
 
 | Datei | Zweck |
 |---|---|
-| `Claude Live Dashboard-1.0.0-x64.AppImage` | läuft ohne Installation |
-| `Claude Live Dashboard-1.0.0-amd64.deb` | Installation per `sudo apt install ./…deb` |
+| `Claude Live Dashboard-<version>-x64.AppImage` | läuft ohne Installation |
+| `Claude Live Dashboard-<version>-amd64.deb` | Installation per `sudo apt install ./…deb` |
 
 Das AppImage muss einmal ausführbar gemacht werden (`chmod +x`) und braucht
 `libfuse2`. Es trägt sich nicht selbst ins Anwendungsmenü ein — der Autostart