feat(release): Veroeffentlichungsvorlage fuer fremde Projekte

Die Anleitung benutzte pack-and-deploy, als laege es im PATH - beziehbar war
es nirgends. Ein Projekt, das den UpdateService einbindet, konnte also nicht
veroeffentlichen, ohne dieses Repository auszuchecken und selbst zu
uebersetzen. Das Werkzeug existierte, nur kam niemand daran.

- build_installer.ps1 baut pack-and-deploy fuer dieselben Laufzeitkennungen
  mit und fuehrt es in installer.json unter "tools". Damit steht es neben dem
  Agenten unter /installer/ bereit.
- Neue Vorlage unter public/docs/release-template/: release.ps1, release.sh
  und release.config.example.json. Kopieren, Konfiguration ausfuellen, fertig -
  die Skripte selbst bleiben unveraendert und lassen sich bei einer neuen
  Fassung einfach ersetzen.
- Sie orchestrieren nur: je Laufzeitkennung einmal dotnet publish, dann
  pack-and-deploy. Pruefsummen, Dateimanifest, latest.json und die Anmeldung
  bleiben im Werkzeug - ein zweiter Ort fuer dieselbe Logik waere ein zweiter
  Ort fuer dieselben Fehler.
- Das Werkzeug wird beim ersten Lauf selbst geholt, gegen die .sha256 geprueft
  und unter .dc-tools/ abgelegt. Die Vorlage ist damit wirklich eine Datei.
- setup.json wird ins Publish-Verzeichnis kopiert, sonst faende der Installer
  sie nicht.
- Rueckgabewert 1 (Konfigurations- oder Versionsfehler) bricht sofort ab; die
  weiteren Plattformen wuerden genauso scheitern. Bei 2 laeuft es weiter und
  meldet am Ende, welche betroffen sind.

Anleitung: public/docs/release.md, oeffentlich unter /docs/release.md - dort,
wo auch das Bugtracker-Handbuch liegt. Das Entwickler-docs/ wird nicht
ausgeliefert; ein erster Anlauf legte die Vorlage dort ab und war deshalb
nicht abrufbar.

Beim Erproben in einem leeren Projekt aufgefallen und behoben:
- Die Vorlage verlangte jq. Das ist auf den wenigsten Systemen vorinstalliert;
  sie kommt jetzt auch mit Python aus.
- Windows legt unter WindowsApps einen python3-Platzhalter ab, der gefunden
  wird, beim Aufruf aber nur auf den Store verweist. Die Erkennung erprobt den
  Interpreter deshalb, statt nur seine Existenz zu pruefen.
- Der Ternary-Operator in release.ps1 gibt es erst ab PowerShell 7; die
  Vorlage laeuft jetzt auch mit dem mitgelieferten 5.1.

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

docs/README.md

@@ -10,6 +10,7 @@ Monitoring und einen Bugtracker, den Coding-Agenten selbständig bedienen.
 | Dokument | Wofür |
 |---|---|
 | **[UPGRADE.md](./UPGRADE.md)** | **Ablaufplan für die Umstellung auf 2.0.** Enthält Pflichtschritte: Zugangsdaten wechseln, Migration, Evaluator-Cron. |
+| **[Release-Anleitung für Agenten](../public/docs/release.md)** | Ein Projekt veröffentlichungsfähig machen: Vorlage kopieren, konfigurieren, ausliefern |
 | [Agent-Prompt-Vorlage](./AGENT_PROMPT_TEMPLATE.md) | Textbaustein für `CLAUDE.md` / `AGENTS.md` eines Projekts |
 | [Agenten-Handbuch](../public/docs/bugtracker.md) | Vollständige Beschreibung des Bugtracker-Workflows, öffentlich unter `/docs/` |
 

docs/UPDATESERVICE_INTEGRATION_GUIDE.md

@@ -233,6 +233,20 @@ für die API-Antwort. `UpdateCheckResult.LatestRelease` ist in beiden Fällen ei
 
 ## 3. Packaging & Deployment CLI (`pack-and-deploy`)
 
+> **Woher das Werkzeug kommt.** Frühere Fassungen dieser Anleitung benutzten
+> `pack-and-deploy`, als läge es im PATH — beziehbar war es nirgends. Es steht
+> jetzt unter `/installer/` bereit:
+>
+> ```bash
+> wget https://dc.mhdf.de/installer/pack-and-deploy-linux-x64 -O pack-and-deploy
+> chmod +x pack-and-deploy
+> ```
+>
+> Wer nicht von Hand aufrufen will, nimmt die **Release-Vorlage**: ein Skript
+> zum Kopieren ins eigene Projekt, das je Plattform `dotnet publish` und
+> `pack-and-deploy` verkettet und sich das Werkzeug selbst holt. Siehe
+> **[Release-Anleitung für Agenten](../public/docs/release.md)**.
+
 Das Packaging-Tool verpackt den `dotnet publish`-Output, berechnet Hashes, erzeugt das `manifest.json` und lädt alles per FTP auf den LEMP-Server.
 
 ### Aufruf-Beispiel: