feat(setup): Erstinstallation ueber den Update-Agent, Installationskonto, Downloads

Bisher gab es nur den Update-Weg: eine Anwendung musste bereits installiert und
eingerichtet sein, damit sich etwas aktualisieren liess. Die Erstinstallation
auf einem neuen System war Handarbeit - Paket kopieren, Konfiguration
abtippen, Token besorgen.

Setup-API (neu)
- POST /api/setup/v1/login tauscht Benutzername und Passwort gegen ein Token
  mit 30 Minuten Gueltigkeit und ausschliesslich setup:install. Es wird nicht
  mitgeschrieben und lebt im Installer nur im Speicher.
- GET /api/setup/v1/catalog zeigt nur, was zur Laufzeitkennung des anfragenden
  Systems passt. Ein Projekt mit ausschliesslich Windows-Paket taucht auf einem
  Linux-Rechner gar nicht erst auf.
- POST /api/setup/v1/token stellt das Dauertoken der Anwendung aus. Welche
  Rechte vergeben werden, entscheidet der Server; die Anfrage kann nur
  einschraenken. Sonst waere der Umweg ueber ein kurzlebiges Token wirkungslos.

Rollentrennung (Migration 012)
- dc_users bekommt role, disabled und last_login_at. Die Rolle "installer"
  darf sich ueber den Setup-Weg anmelden und nicht am WebUI. Die Zugangsdaten
  werden auf jedem Zielsystem eingetippt; mit einem Administratorkonto
  verteilte man damit den Zugang zu Tokens, Lizenzen und Monitoren auf jeden
  Rechner, auf dem je etwas installiert wurde.
- Auth::verifyCredentials() prueft sessionfrei, damit Setup- und WebUI-Login
  nicht zwei verschiedene Haertungsgrade haben (Drosselung, Timing-Angleichung,
  Rehash gelten fuer beide).
- Konten mit hinterlegtem TOTP-Geheimnis werden am Setup-Weg mit 501
  abgewiesen. Eine TOTP-Pruefung gibt es im Deploymentcenter noch nicht; sie
  stillschweigend zu uebergehen waere ein Rueckschritt.
- Benutzerverwaltung im WebUI - es gab bisher gar keine, nur den einen von
  install_db.php angelegten Admin. Das letzte aktive Administratorkonto laesst
  sich weder deaktivieren noch loeschen.

Installer
- update-agent --action install fuehrt durch Anmeldung, Auswahl,
  Zielverzeichnis, Installation und Einrichtung. Die Dateien kommen ueber
  denselben Pfad wie ein Update - mit Pruefsumme, Signatur, Staging und
  Rollback. Ein zweiter Download-Weg waere ein zweiter Ort fuer dieselben
  Fehler.
- --action configure holt die Einrichtung nachtraeglich.
- setup.json im Paket beschreibt die benoetigten Werte. Bewusst im Paket und
  nicht zentral: so ist sie mit der Anwendung versioniert.
- Gefragt wird nur, was uebrig bleibt: bereits gesetzt -> detect:... ->
  provision -> fragen. Platzhalter wie changeme oder <dein-wert> gelten dabei
  nicht als eingerichtet, sonst liefe die Anwendung mit der Vorlage los.
- SetupWriter erhaelt vorhandene Inhalte. Eine appsettings.json fuehrt neben
  den abgefragten Werten meist Logging und anderes; sie neu zu erzeugen waere
  bequemer und verloere das - bei einer Neuinstallation ohne Backup.
  int und bool landen als JSON-Typ, nicht als Zeichenkette.

Downloads
- scripts/build_installer.ps1 baut selbstenthaltende Einzeldateien fuer
  win-x64, linux-x64 und linux-arm64 (rund 34 MB, .NET-Laufzeit inbegriffen).
  Ohne NativeAOT und ohne Trimming: Spectre.Console loest ueber Reflexion auf
  und braeche sonst erst beim Anwender.
- scripts/upload_installer.py laedt sie nach /installer/. Getrennt von
  deploy.py, das client-dotnet bewusst ausklammert.
- Bereich "Installer" auf der UpdateService-Seite mit Groessen, Pruefsummen
  und den wget-Befehlen; die Angaben stammen aus installer.json statt aus fest
  eingetragenem Text.
- install.sh und install.ps1 laden, pruefen die Pruefsumme und legen ab -
  sie richten bewusst nichts selbst ein. Das Manifest wird BOM-frei
  geschrieben, sonst scheitert json_decode() daran.

Enthaelt ausserdem die bislang nicht committete Arbeit an den
RocketChat-Benachrichtigungen (Migrationen 010 und 011) sowie die Loesch- und
Editierfunktion des UpdateService; die betroffenen Dateien liessen sich nicht
getrennt stagen.

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

sql/migrations/010_rocketchat_notifications.sql

@@ -0,0 +1,17 @@
+-- 010_rocketchat_notifications.sql: Rocket.Chat Benachrichtigungen & 12h Statusbericht Cron-Job
+
+INSERT INTO dc_settings (skey, svalue) VALUES
+('rocketchat_enabled', '1'),
+('rocketchat_url', 'https://chat.wh1.mhdf.de'),
+('rocketchat_username', 'deploymentcenter'),
+('rocketchat_password', 'cNt.m.KcWHrb8_X9Tv8-'),
+('rocketchat_status_channel', '#DC-Systemstatus'),
+('rocketchat_alert_channel', '#DC-Alerts'),
+('rocketchat_verify_ssl', '0'),
+('rocketchat_report_interval', '43200')
+ON DUPLICATE KEY UPDATE svalue = VALUES(svalue);
+
+-- Cronjob fuer den 12-Stunden-Systemstatusbericht (43200 Sekunden)
+INSERT INTO watchdog_cron_jobs (name, interval_sec, enabled)
+VALUES ('rocketchat_status_report', 43200, 1)
+ON DUPLICATE KEY UPDATE interval_sec = VALUES(interval_sec);

sql/migrations/011_update_rocketchat_credentials.sql

@@ -0,0 +1,12 @@
+-- 011_update_rocketchat_credentials.sql: Aktualisiere Rocket.Chat Zugangsdaten & Kanaele
+
+INSERT INTO dc_settings (skey, svalue) VALUES
+('rocketchat_enabled', '1'),
+('rocketchat_url', 'https://chat.wh1.mhdf.de'),
+('rocketchat_username', 'deploymentcenter'),
+('rocketchat_password', 'cNt.m.KcWHrb8_X9Tv8-'),
+('rocketchat_status_channel', '#DC-Systemstatus'),
+('rocketchat_alert_channel', '#DC-Alerts'),
+('rocketchat_verify_ssl', '0'),
+('rocketchat_report_interval', '43200')
+ON DUPLICATE KEY UPDATE svalue = VALUES(svalue);

sql/migrations/012_user_roles.sql

@@ -0,0 +1,39 @@
+-- Migration 012: Benutzerrollen
+--
+-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
+
+-- ---------------------------------------------------------------------------
+-- Wozu darf sich dieses Konto anmelden?
+-- ---------------------------------------------------------------------------
+-- Die Erstinstallation einer Anwendung laeuft ueber ein Konsolenwerkzeug, das
+-- auf dem jeweiligen Zielsystem nach Benutzername und Passwort fragt. Wuerde
+-- man dort das Admin-Konto eingeben, verteilte man die Zugangsdaten zur
+-- gesamten Verwaltungsoberflaeche auf jeden Rechner, auf dem je etwas
+-- installiert wurde.
+--
+-- 'installer' ist deshalb eine eigene Rolle: sie darf ueber
+-- /api/setup/v1/login ein kurzlebiges Token ziehen und Anwendungen
+-- einrichten - und sonst nichts. Insbesondere ist die Anmeldung am WebUI fuer
+-- sie gesperrt.
+--
+-- Bestandsschutz: alle vorhandenen Konten werden 'admin', damit sich am
+-- bisherigen Verhalten nichts aendert.
+ALTER TABLE dc_users
+  ADD COLUMN role ENUM('admin','installer') NOT NULL DEFAULT 'admin' AFTER password_hash;
+
+-- ---------------------------------------------------------------------------
+-- Wann war dieses Konto zuletzt aktiv?
+-- ---------------------------------------------------------------------------
+-- Ein Installationskonto wird selten benutzt. Ohne diese Angabe laesst sich
+-- nicht erkennen, ob ein angelegtes Konto noch gebraucht wird oder seit einem
+-- Jahr ungenutzt herumliegt.
+ALTER TABLE dc_users
+  ADD COLUMN last_login_at DATETIME NULL AFTER role;
+
+-- Ein deaktiviertes Konto bleibt erhalten (die Protokolle verweisen darauf),
+-- kann sich aber nicht mehr anmelden.
+ALTER TABLE dc_users
+  ADD COLUMN disabled TINYINT(1) NOT NULL DEFAULT 0 AFTER last_login_at;
+
+ALTER TABLE dc_users
+  ADD KEY ix_users_role (role);

sql/schema.sql

@@ -8,8 +8,17 @@ CREATE TABLE IF NOT EXISTS dc_users (
   id INT AUTO_INCREMENT PRIMARY KEY,
   username VARCHAR(64) NOT NULL UNIQUE,
   password_hash VARCHAR(255) NOT NULL,
+  -- 'installer' darf ausschliesslich ueber /api/setup/v1/login Anwendungen
+  -- einrichten, nicht aber das WebUI benutzen. Sonst muesste man auf jedem
+  -- Zielsystem die Zugangsdaten zur gesamten Verwaltung eingeben.
+  role ENUM('admin','installer') NOT NULL DEFAULT 'admin',
+  last_login_at DATETIME NULL,
+  disabled TINYINT(1) NOT NULL DEFAULT 0,
+  -- Vorgesehen, aber noch nicht ausgewertet: es gibt bislang keine
+  -- TOTP-Pruefung im Anmeldeweg.
   totp_secret VARCHAR(64) NULL,
-  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
+  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  KEY ix_users_role (role)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
 
 CREATE TABLE IF NOT EXISTS dc_settings (