fix(client): Schluessel raus aus argv, Wartezeit einstellbar, Packager sperrt

Fuenf von sechs Befunden einer externen Integration. Der sechste - unsignierte
Lizenzurteile - ist bestaetigt, aber bewusst nicht Teil dieses Commits.

1. Lizenzschluessel stand in der Kommandozeile
   Der Agent nahm --license-key nur als Argument und las keine
   Umgebungsvariablen. "ps" zeigt argv jedem Benutzer der Maschine - exakt die
   Begruendung, mit der UPGRADE.md §5 den Crontab-Weg verwirft. Damit nahm das
   SDK einen bereits geloesten Sicherheitsbefund zurueck.
   Der Agent liest jetzt DC_LICENSE_KEY, DC_DOWNLOAD_USER und
   DC_DOWNLOAD_PASSWORD, Umgebung vor Argument. LaunchUpdateAgent uebergibt
   den Schluessel nicht mehr als Argument, sondern setzt die Variable auf dem
   eigenen Prozess: das Kind erbt den Umgebungsblock, danach wird sie wieder
   entfernt. Das funktioniert auch mit UseShellExecute=true, wo sich
   ProcessStartInfo.Environment nicht setzen laesst.

2. --wait-timeout war nicht durchgereicht
   Der Agent kannte den Parameter, LaunchUpdateAgent hatte keinen dafuer - es
   galten fest 60 Sekunden. Eine Anwendung, die allein fuer host.StopAsync 30
   Sekunden braucht, kommt damit gefaehrlich nah an die Grenze. Neu:
   waitTimeoutSeconds. Ausserdem ist im Quelltext und in der Doku jetzt
   festgehalten, dass exitCurrentApp:true ueber Environment.Exit(0) laeuft und
   damit finally-Bloecke und IHostApplicationLifetime uebergeht - bei offenem
   Zustand die falsche Wahl.

3. ILicensePrompt war tot
   Der Konstruktor nahm es entgegen, legte es in _prompt ab und benutzte es
   nirgends. Wer darauf eine headless-Story aufbaute, baute auf Sand. Neu:
   EnsureLicensedAsync() - zwischengespeicherten Schluessel nehmen, sonst
   fragen, pruefen, bei Ablehnung erneut fragen. allowPrompt:false lehnt ohne
   Cache ab, statt auf eine Eingabe zu warten, die im Dienst nie kommt. Ein
   voruebergehender Netzfehler fuehrt nicht zur erneuten Abfrage - der
   Schluessel ist ja nicht falsch.

4. Der Packager warnte nur
   Er bricht jetzt ab. Anlass war ein echter API-Schluessel in einem
   oeffentlich abrufbaren Paket - und die Warnung war damals ausgerechnet
   unterdrueckt, weil die Datei auf der preserve-Liste stand.
   Zwei Stufen: Dateiname (appsettings.Local.json, master.key, *.pfx, *.db,
   server_settings.xml) und Inhalt (gefuelltes Password=, sk-, ghp_,
   dc_master_, AKIA, private Schluessel). Die Inhaltspruefung findet auch
   Dateien mit unverdaechtigem Namen.
   Platzhalter loesen bewusst nicht aus: "sk-DEIN-SCHLUESSEL-HIER" haette
   sonst jede ausgelieferte Vorlage blockiert, und --allow-secrets waere nach
   einer Woche Gewohnheit. Beim Erproben zuerst genau in diese Falle gelaufen.

5. BuildInfo.targets war nur per Pfad-Import zu haben
   Die Anleitung empfahl einen <Import> ins Nachbar-Repository - das setzt
   voraus, dass beide Arbeitskopien nebeneinander liegen und in derselben
   Fassung stehen. Das Client-Projekt ist jetzt packbar und legt das Target
   unter build/ ins Paket, wo NuGet es selbst importiert.

Ausserdem: Unauthorized wurde nur im statischen Zweig erkannt, im API-Zweig
kam ein 401 als gewoehnlicher HTTP-Fehler an.

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

client-dotnet/Deploymentcenter.Client/UpdateClient.cs

@@ -123,6 +123,17 @@ namespace Deploymentcenter.Client
                     response = await _httpClient.GetAsync(apiUrl, cancellationToken).ConfigureAwait(false);
                 }
 
+                // Auch der API-Zweig kann 401 liefern - etwa wenn die
+                // Lese-Endpunkte spaeter ebenfalls hinter den Zugangsschutz
+                // wandern. Zuvor wurde das nur auf dem statischen Weg erkannt
+                // und hier als gewoehnlicher HTTP-Fehler gemeldet.
+                if (response.StatusCode == HttpStatusCode.Unauthorized)
+                {
+                    result.Unauthorized = true;
+                    result.Message = ReleaseCredentials.DescribeUnauthorized(credentials);
+                    return result;
+                }
+
                 if (!response.IsSuccessStatusCode)
                 {
                     result.Message = $"Update-Pruefung fehlgeschlagen: HTTP {(int)response.StatusCode}";
@@ -339,7 +350,8 @@ namespace Deploymentcenter.Client
             string? currentVersion = null,
             string? platform = null,
             bool waitForCurrentProcess = true,
-            string? licenseKey = null)
+            string? licenseKey = null,
+            int waitTimeoutSeconds = 60)
         {
             if (!File.Exists(agentPath))
             {
@@ -361,17 +373,37 @@ namespace Deploymentcenter.Client
                 AppendArg(args, "--current-version", currentVersion!);
             }
 
-            // Ohne den Schluessel kommt der Agent nicht mehr an die Pakete -
-            // die Release-Ablage verlangt seit Version 2.4 Zugangsdaten.
+            // Der Lizenzschluessel wird BEWUSST NICHT als Argument uebergeben.
+            //
+            // Was in argv steht, zeigt "ps" jedem Benutzer der Maschine. Aus
+            // genau diesem Grund verwirft UPGRADE.md §5 den Weg, den Shared
+            // Key im Crontab zu hinterlegen - fuer einen Lizenzschluessel
+            // gilt dasselbe.
+            //
+            // Stattdessen wird die Variable auf dem eigenen Prozess gesetzt;
+            // der Agent erbt den Umgebungsblock beim Start und liest sie dort.
+            // Das funktioniert auch mit UseShellExecute=true, wo sich
+            // ProcessStartInfo.Environment nicht setzen laesst.
+            bool licenseKeySet = false;
+
             if (!string.IsNullOrWhiteSpace(licenseKey))
             {
-                AppendArg(args, "--license-key", licenseKey!);
+                Environment.SetEnvironmentVariable("DC_LICENSE_KEY", licenseKey);
+                licenseKeySet = true;
             }
 
             if (waitForCurrentProcess)
             {
                 AppendArg(args, "--wait-for-pid",
                     Process.GetCurrentProcess().Id.ToString(System.Globalization.CultureInfo.InvariantCulture));
+
+                // Ohne diesen Wert galten fest 60 Sekunden. Eine Anwendung,
+                // die allein fuer host.StopAsync 30 Sekunden braucht, kommt
+                // damit gefaehrlich nah an die Grenze - und laeuft sie ab,
+                // bricht der Agent ab, statt ueber gesperrte Dateien zu
+                // schreiben. Sicher, aber eben auch kein Update.
+                AppendArg(args, "--wait-timeout",
+                    Math.Max(5, waitTimeoutSeconds).ToString(System.Globalization.CultureInfo.InvariantCulture));
             }
 
             // Ohne ausdruecklichen Pfad die eigene ausfuehrbare Datei.
@@ -394,10 +426,31 @@ namespace Deploymentcenter.Client
                 UseShellExecute = true
             };
 
-            Process.Start(startInfo);
+            try
+            {
+                Process.Start(startInfo);
+            }
+            finally
+            {
+                // Nach dem Start wieder entfernen: Der Schluessel soll nur so
+                // lange im eigenen Umgebungsblock stehen, wie er zum Vererben
+                // gebraucht wird.
+                if (licenseKeySet)
+                {
+                    Environment.SetEnvironmentVariable("DC_LICENSE_KEY", null);
+                }
+            }
 
             if (exitCurrentApp)
             {
+                // Environment.Exit beendet den Prozess sofort: laufende
+                // finally-Bloecke anderer Threads, IHostApplicationLifetime
+                // und Destruktoren kommen nicht mehr zum Zug. Fuer eine
+                // Anwendung mit offenem Zustand - Positionen, Transaktionen,
+                // ungeschriebene Puffer - ist das die falsche Wahl. Dort
+                // gehoert exitCurrentApp:false gesetzt und danach der eigene
+                // geordnete Weg gegangen; der Agent wartet ohnehin auf das
+                // Prozessende.
                 Environment.Exit(0);
             }