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>

sql/migrations/008_watchdog_app_version.sql

@@ -0,0 +1,22 @@
+-- Migration 008: Anwendungsversion am Heartbeat
+--
+-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062.
+
+-- ---------------------------------------------------------------------------
+-- Welche Version laeuft auf diesem Monitor?
+-- ---------------------------------------------------------------------------
+-- Der Fehler-Stream fuehrt build_version, der Bugtracker ebenso, die
+-- Aktivierungsliste des Lizenzmoduls app_version - nur der Watchdog konnte
+-- nicht sagen, welche Version eines Dienstes tatsaechlich laeuft. Damit war
+-- eine Aussage wie "Monitor X ist seit dem Rollout von 1.4.3 unten" nur ueber
+-- Umwege zu bekommen.
+--
+-- Das Feld ist optional; bestehende Agenten senden es nicht und bleiben
+-- unveraendert lauffaehig.
+ALTER TABLE watchdog_monitors
+  ADD COLUMN app_version VARCHAR(64) NULL AFTER os;
+
+-- Rollouts lassen sich damit gruppieren: "zeige alle Monitore, die noch auf
+-- der Vorversion stehen".
+ALTER TABLE watchdog_monitors
+  ADD KEY ix_wd_app_version (app_version);

sql/migrations/009_updateservice_platform.sql

@@ -0,0 +1,55 @@
+-- Migration 009: Plattform-Dimension im UpdateService
+--
+-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
+
+-- ---------------------------------------------------------------------------
+-- Fuer welche Plattform gilt dieses Release?
+-- ---------------------------------------------------------------------------
+-- Der UpdateService kannte Produkt, Kanal und Version - aber keine Plattform.
+-- Seit fuer mehrere Laufzeitkennungen gebaut wird (win-x64, linux-x64, ...)
+-- landeten beide Pakete im selben Kanal unter derselben Version und
+-- ueberschrieben sich gegenseitig; ein Linux-System zog sich das
+-- Windows-Paket. Behelfe waren getrennte Produkt-Slugs oder zweckentfremdete
+-- Kanaele - beides trug nicht weit.
+--
+-- 'any' ist der Wert fuer plattformunabhaengige Releases und zugleich der
+-- Bestandsschutz: alles, was vor dieser Migration veroeffentlicht wurde, gilt
+-- weiterhin fuer jeden Client, der keine Plattform mitschickt.
+ALTER TABLE updateservice_releases
+  ADD COLUMN platform VARCHAR(32) NOT NULL DEFAULT 'any' AFTER channel;
+
+-- Die Eindeutigkeit muss die Plattform einschliessen, sonst verdraengt das
+-- zuletzt veroeffentlichte Paket einer Version alle anderen Plattformen
+-- derselben Version (ON DUPLICATE KEY UPDATE greift auf dem alten Schluessel).
+ALTER TABLE updateservice_releases
+  DROP INDEX uq_prod_ver_chan;
+
+ALTER TABLE updateservice_releases
+  ADD UNIQUE KEY uq_prod_ver_chan_plat (product_slug, version, channel, platform);
+
+-- Die Abfrage lautet immer "Produkt + Kanal + passende Plattform".
+ALTER TABLE updateservice_releases
+  ADD KEY ix_us_lookup (product_slug, channel, platform);
+
+-- ---------------------------------------------------------------------------
+-- Signatur des Releases
+-- ---------------------------------------------------------------------------
+-- Der SHA256 eines Pakets stammt aus derselben Quelle wie das Paket selbst.
+-- Das schuetzt gegen Uebertragungsfehler, nicht gegen einen manipulierten
+-- Webroot oder gestohlene FTP-Zugangsdaten - ausgerechnet auf dem Pfad, der
+-- fremden Code ausfuehrt.
+--
+-- Bewusst KEIN HMAC: Bei einem HMAC braucht der Pruefende denselben
+-- geheimen Schluessel wie der Signierende. Der Agent laeuft auf fremden
+-- Systemen; ein dort hinterlegter Schluessel koennte gestohlen und zum
+-- Signieren beliebiger Pakete benutzt werden - die Signatur waere wertlos.
+-- Beim Lizenzmodul geht HMAC auf, weil dort der Server prueft.
+--
+-- Stattdessen RSA-SHA256: der Server signiert mit dem privaten Schluessel
+-- (security.release_private_key), der Agent prueft mit dem oeffentlichen aus
+-- /api/updateservice/v1/pubkey. Base64 einer 2048-bit-Signatur sind 344
+-- Zeichen, daher TEXT und nicht VARCHAR(64).
+--
+-- Optional: Releases ohne Signatur bleiben installierbar, der Agent warnt.
+ALTER TABLE updateservice_releases
+  ADD COLUMN manifest_signature TEXT NULL AFTER manifest_json;

sql/schema.sql

@@ -94,6 +94,8 @@ CREATE TABLE IF NOT EXISTS watchdog_monitors (
   is_muted              TINYINT(1)    NOT NULL DEFAULT 0,
   expect_running        TINYINT(1)    NOT NULL DEFAULT 1,
   os                    VARCHAR(50)   NULL,
+  -- Version der laufenden Anwendung, vom Heartbeat mitgeliefert (optional).
+  app_version           VARCHAR(64)   NULL,
   first_contact_deadline_utc DATETIME NULL,
   ack_until_utc         DATETIME      NULL,
   acknowledged_by       VARCHAR(100)  NULL,
@@ -168,15 +170,25 @@ CREATE TABLE IF NOT EXISTS updateservice_releases (
   product_slug VARCHAR(64) NOT NULL,
   version VARCHAR(32) NOT NULL,
   channel VARCHAR(32) NOT NULL DEFAULT 'prod',
+  -- Laufzeitkennung (win-x64, linux-x64, ...) oder 'any' fuer
+  -- plattformunabhaengige Releases. Ohne diese Spalte ueberschrieben sich
+  -- Pakete verschiedener Plattformen derselben Version gegenseitig.
+  platform VARCHAR(32) NOT NULL DEFAULT 'any',
   release_notes TEXT NULL,
   download_url VARCHAR(255) NOT NULL,
   sha256_hash VARCHAR(64) NULL,
   git_commit VARCHAR(64) NULL,
   size_bytes BIGINT NOT NULL DEFAULT 0,
   manifest_json JSON NULL,
+  -- RSA-SHA256 ueber die kanonische Release-Zeile, base64-kodiert. Signiert
+  -- mit security.release_private_key, geprueft vom Agenten gegen den
+  -- oeffentlichen Schluessel. Kein HMAC - der Pruefende laeuft auf fremden
+  -- Systemen und darf den Signierschluessel nicht besitzen.
+  manifest_signature TEXT NULL,
   is_critical TINYINT(1) NOT NULL DEFAULT 0,
   created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
-  UNIQUE KEY uq_prod_ver_chan (product_slug, version, channel)
+  UNIQUE KEY uq_prod_ver_chan_plat (product_slug, version, channel, platform),
+  KEY ix_us_lookup (product_slug, channel, platform)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
 
 -- 5. Core Token Hierarchy & Bugtracker Tables