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>

docs/UPDATESERVICE_INTEGRATION_GUIDE.md

@@ -164,16 +164,28 @@ ein Dienst-Manager den Neustart übernimmt.
 
 ### B. MSBuild BuildInfo Generierung
 
-Binde das `Deploymentcenter.BuildInfo.targets` Script in deine `.csproj` ein, damit Version, UTC-Build-Datum und Git Commit-Hash automatisch zur Übersetzungszeit generiert werden:
+Version, UTC-Build-Datum und Git-Commit entstehen automatisch zur
+Übersetzungszeit. **Seit Version 2.5 genügt dafür der Paketverweis:**
 
 ```xml
 <PropertyGroup>
   <Version>1.4.3</Version>
 </PropertyGroup>
 
-<Import Project="..\Deploymentcenter.Client\Deploymentcenter.BuildInfo.targets" />
+<ItemGroup>
+  <PackageReference Include="Deploymentcenter.Client" Version="2.5.0" />
+</ItemGroup>
 ```
 
+Das Targets-File liegt im Paket unter `build/` und wird von NuGet selbst
+importiert — ein `<Import>` von Hand entfällt.
+
+> **Der bisherige Weg koppelte zwei Repositories.** Die Anleitung empfahl
+> `<Import Project="..\Deploymentcenter.Client\Deploymentcenter.BuildInfo.targets" />`
+> — das setzt voraus, dass beide Arbeitskopien nebeneinander liegen und in
+> derselben Fassung stehen. Wer nur das Paket bezieht, hatte das Target nicht.
+> Der Import per Pfad funktioniert weiterhin, ist aber nicht mehr nötig.
+
 Die Klasse entsteht im Namensraum deines Projekts (`$(RootNamespace)`), nicht im
 SDK. Du erreichst sie also ohne `using`:
 
@@ -360,8 +372,27 @@ Die Muster sind jetzt echte Globs:
 | `wwwroot/**/*.css` | auch in Unterverzeichnissen |
 | `appsettings*.json` | `appsettings.json`, `appsettings.Production.json`, … |
 
-Der Packager warnt zusätzlich von sich aus, wenn eine Datei nach Zugangsdaten
-aussieht und auf keiner der beiden Listen steht.
+### Der Packager bricht bei Zugangsdaten ab
+
+Seit Version 2.5 nicht mehr nur eine Warnung. Anlass war ein echter
+API-Schlüssel, der so in ein öffentlich abrufbares Paket geriet — und die
+Warnung wurde damals ausgerechnet unterdrückt, weil die Datei auf der
+`preserve`-Liste stand.
+
+| Stufe | Findet |
+|---|---|
+| Dateiname | `appsettings.Local.json`, `secrets.json`, `master.key`, `*.pfx`, `*.db`, `server_settings.xml`, … |
+| Inhalt | gefüllte `Password=`-Felder, `sk-…`, `ghp_…`, `dc_master_…`, `AKIA…`, private Schlüssel |
+
+Die Inhaltsprüfung findet auch Dateien mit unverdächtigem Namen. Platzhalter
+wie `sk-DEIN-SCHLUESSEL-HIER` oder `Password=changeme` lösen **nicht** aus —
+sonst würde jede ausgelieferte Vorlage den Build blockieren, und
+`--allow-secrets` wäre nach einer Woche Gewohnheit.
+
+**Der Zugangsschutz macht das nicht harmlos.** Ein Schlüssel im Paket ist dann
+für jeden Lizenznehmer lesbar statt für alle — besser, aber immer noch falsch.
+
+Notausgang für bewusste Fälle: `--allow-secrets`.
 
 ### Versionsgegenprobe
 
@@ -678,14 +709,51 @@ UpdateClient.LaunchUpdateAgent(
     licenseKey: meineLizenz);      // reicht --license-key an den Agenten durch
 ```
 
-Auf der Kommandozeile:
+Auf der Kommandozeile — **bevorzugt über die Umgebung**:
 
 ```bash
-update-agent --project myapp --action update --license-key XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
+DC_LICENSE_KEY=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX \
+  update-agent --project myapp --action update
 ```
 
-Ersatzweise `--download-user` und `--download-password` für ein
-Installationskonto — das nutzt der Installer bei der Erstinstallation.
+`--license-key` gibt es weiterhin, ist aber die schlechtere Wahl: Was in `argv`
+steht, zeigt `ps` jedem Benutzer der Maschine. Aus genau diesem Grund verwirft
+[UPGRADE.md §5](./UPGRADE.md#5-cron-für-den-watchdog-evaluator-einrichten) den
+Weg, den Shared Key im Crontab zu hinterlegen — für einen Lizenzschlüssel gilt
+dasselbe. Umgebungsvariablen haben Vorrang vor den Argumenten.
+
+`LaunchUpdateAgent` übergibt den Schlüssel deshalb **nicht** als Argument: Es
+setzt `DC_LICENSE_KEY` auf dem eigenen Prozess, der Agent erbt den
+Umgebungsblock beim Start, und danach wird die Variable wieder entfernt.
+
+Ersatzweise `DC_DOWNLOAD_USER` und `DC_DOWNLOAD_PASSWORD` (oder
+`--download-user` / `--download-password`) für ein Installationskonto — das
+nutzt der Installer bei der Erstinstallation.
+
+### Wartezeit beim Übergeben
+
+`LaunchUpdateAgent` gibt dem Agenten mit, wie lange er auf das Ende der
+Anwendung warten soll. Vorgabe sind 60 Sekunden:
+
+```csharp
+UpdateClient.LaunchUpdateAgent(
+    agentPath:           agentPath,
+    projectId:           "myapp",
+    licenseKey:          meineLizenz,
+    waitTimeoutSeconds:  180,      // reicht auch für ein langsames StopAsync
+    exitCurrentApp:      false);   // siehe unten
+```
+
+Läuft die Zeit ab, **bricht der Agent ab, ohne etwas zu verändern** — sicher,
+aber eben auch kein Update. Wer allein für `host.StopAsync` 30 Sekunden
+braucht, sollte den Wert heraufsetzen.
+
+> **`exitCurrentApp: true` beendet den Prozess mit `Environment.Exit(0)`.**
+> Laufende `finally`-Blöcke anderer Threads, `IHostApplicationLifetime` und
+> Destruktoren kommen dann nicht mehr zum Zug. Für eine Anwendung mit offenem
+> Zustand — Positionen, Transaktionen, ungeschriebene Puffer — ist das die
+> falsche Wahl. Dort `exitCurrentApp: false` setzen und anschließend den
+> eigenen geordneten Weg gehen; der Agent wartet ohnehin auf das Prozessende.
 
 `UpdateCheckResult.Unauthorized` ist bewusst von einem gewöhnlichen Fehler
 getrennt. Ohne diese Unterscheidung sieht ein abgelaufener Vertrag aus wie eine