feat(updateservice): Plattform-Dimension, signierte Releases, Update mit Rollback

Behebt eine Reihe zusammenhaengender Fehler im Update-Weg, die zusammen
verhindert haben, fuer mehr als eine Plattform auszuliefern - und die im
Fehlerfall halb aktualisierte Installationen hinterliessen.

Server
- Migration 009: Spalte platform samt neuem Unique-Key. Zuvor verdraengte das
  zuletzt veroeffentlichte Paket alle anderen Plattformen derselben Version,
  weil ON DUPLICATE KEY auf (slug, version, channel) griff. Ein Linux-System
  zog sich damit das Windows-Paket.
- Aufloesungsregel: je Version das plattformgenaue Paket, sonst das
  plattformunabhaengige. Ein Client ohne Plattformangabe sieht ausschliesslich
  'any' - lieber kein Update als das falsche.
- manifest_json wird endlich befuellt; die Spalte blieb bisher immer leer,
  wodurch die API nie der Rueckfall sein konnte, als der sie gedacht war.
- Releases werden serverseitig mit RSA-SHA256 signiert, neuer Endpunkt
  /api/updateservice/v1/pubkey. Bewusst kein HMAC: der Pruefende laeuft auf
  fremden Systemen und darf den Signierschluessel nicht besitzen.

Packager
- Bricht ab, statt die Versionshistorie zu verlieren. Schlug das Lesen der
  bestehenden latest.json fehl, ersetzte ein leeres catch die komplette
  Historie durch einen einzigen Eintrag - ohne jede Meldung.
- Echte Glob-Muster. Zuvor trafen "logs/**" und "scratch/**" aus der
  mitgelieferten Beispielkonfiguration nie zu.
- preservePatterns: Konfigurationsvorlagen werden ausgeliefert, ersetzen am
  Ziel aber keine vorhandene Datei. Eine settings.json mit Zugangsdaten
  ueberschrieb bisher beim Update die Konfiguration jedes Zielsystems.
- Warnt vor Dateien, die nach Zugangsdaten aussehen und auf keiner Liste stehen.
- Prueft --version gegen die Hauptassembly. Eine Abweichung fuehrte zu einer
  Endlosschleife: Clients aktualisieren, melden weiter die alte Version,
  halten das Release erneut fuer neu.
- --platform mit Ableitung aus dem Publish-Pfad.

Agent
- Anwenden mit Plan, Backup und vollstaendigem Rollback. Die Stelle war als
  "Atomic Replace with Backup" kommentiert und war eine Kopierschleife.
- Verwaiste Dateien werden entfernt, aber nur solche aus dem Manifest der
  Vorversion. Was nicht aus einem Release stammt, bleibt liegen.
- Das laufende Agent-Binary wird zur Seite gelegt statt ueberschrieben.
- API-Rueckfall in FetchManifestAsync; bisher nur im SDK vorhanden, weshalb
  die Anwendung "Update verfuegbar" und der Agent "kein Release" sagen konnte.
- Installierte Version aus --current-version oder manifest.json statt des
  Textes "Unbekannt", der als 0 gelesen wurde und jede Version neuer erscheinen
  liess. Reparatur funktioniert damit auch ohne manifest.json.
- Setzt das Ausfuehrungsbit fuer Linux-Pakete, die unter Windows gebaut wurden.

SDK
- ResolveAgentPath() liefert den plattformrichtigen Namen; ein fest verdrahtetes
  "update-agent.exe" wird unter Linux nie gefunden.
- LaunchUpdateAgent uebergibt jetzt --restart (wurde nie uebergeben, die
  Anwendung blieb nach dem Update zu), --wait-for-pid (kein Wettlauf mehr mit
  dem Herunterfahren) und --platform.

Enthaelt ausserdem die bislang nicht committete Arbeit an Watchdog, Lizenz-
Client und cli/tick.php samt Migration 008; die betroffenen Dateien liessen
sich nicht getrennt stagen.

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

src/Modules/Watchdog/MonitorRepo.php

@@ -86,7 +86,8 @@ final class MonitorRepo
         ?string $message,
         ?string $groupKey = null,
         ?string $os = null,
-        $checks = null
+        $checks = null,
+        ?string $appVersion = null
     ): array {
         $metricsJson = (is_array($metrics) || is_object($metrics))
             ? json_encode($metrics, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
@@ -139,11 +140,11 @@ final class MonitorRepo
             INSERT INTO watchdog_monitors (
                 source, instance, type, state, last_state_change_utc, expected_interval_sec,
                 last_seen_utc, last_status, last_message, metrics_json, health_json,
-                failing_checks, group_key, os, created_utc, updated_utc
+                failing_checks, group_key, os, app_version, created_utc, updated_utc
             ) VALUES (
                 :source, :instance, :type, :state, UTC_TIMESTAMP(), :interval,
                 UTC_TIMESTAMP(), :last_status, :message, :metrics, :health,
-                :failing, :group_key, :os, UTC_TIMESTAMP(), UTC_TIMESTAMP()
+                :failing, :group_key, :os, :app_version, UTC_TIMESTAMP(), UTC_TIMESTAMP()
             )
             ON DUPLICATE KEY UPDATE
                 -- Reihenfolge ist relevant: MySQL wertet die Zuweisungen von
@@ -161,6 +162,9 @@ final class MonitorRepo
                 failing_checks        = VALUES(failing_checks),
                 group_key             = COALESCE(VALUES(group_key), group_key),
                 os                    = COALESCE(VALUES(os), os),
+                -- COALESCE, damit ein Agent, der die Version nicht mitschickt,
+                -- eine frueher gemeldete nicht loescht.
+                app_version           = COALESCE(VALUES(app_version), app_version),
                 updated_utc           = VALUES(updated_utc)
         ');
 
@@ -177,6 +181,7 @@ final class MonitorRepo
             ':failing'     => $failing !== [] ? mb_substr(implode(', ', $failing), 0, 255) : null,
             ':group_key'   => $groupKey,
             ':os'          => $os,
+            ':app_version' => $appVersion !== null ? mb_substr($appVersion, 0, 64) : null,
         ]);
 
         $monitor = $this->getMonitor($source, $instance);