docs: Integrationsanleitungen auf Stand 2.0 bringen, Status "stopped" ergänzen

Watchdog-Anleitung vollständig überarbeitet
- Alle drei Codebeispiele trugen das geseedete Demo-Token fest im Quelltext.
  Es ist an die Source "srv-db-01" gebunden — wer es übernommen hätte, wäre für
  jeden anderen Dienst abgewiesen worden. Jetzt Umgebungsvariable und eine
  Anleitung, wie man ein eigenes Token erzeugt.
- Der Ratschlag "sende beim Beenden einen Ping mit Status stopped" beschrieb
  etwas, das die API nicht konnte. Statt die Anleitung an die Lücke anzupassen,
  ist die Lücke geschlossen: status akzeptiert jetzt "stopped" und
  "maintenance". Der Evaluator lässt solche Monitore in Ruhe, statt wenige
  Minuten nach jedem sauberen Shutdown einen Fehlalarm zu erzeugen.
- Neu dokumentiert: checks (Gesundheitszustand per Push, ohne offene Ports),
  metrics samt Verlauf und Abweichungsvergleich, Alarmunterdrückung über die
  Hierarchie, die Schwellen des Evaluators (2x warning, 4x down) und der
  erforderliche Cron-Job.

Lizenz-Anleitung
- Neuer Abschnitt zum Antwortformat. Die Lizenz-Endpunkte antworten bewusst
  ohne den status/error-Umschlag der übrigen API; das Feld status auf oberster
  Ebene trägt den Lizenzzustand. Genau diese Besonderheit hatte ich beim Umbau
  übersehen, weshalb sie jetzt ausdrücklich festgehalten ist — samt Tabelle
  aller Zustände.
- Ergänzt: Deaktivierung braucht den shared_key, mit Beispiel für den .NET-
  Client und curl. Verhalten bei Ratenbegrenzung.

UpdateService-Anleitung
- Prüf-Endpunkte dokumentiert (check, latest, releases) samt Antwortformat.
- Tabelle zum Versionsvergleich mit den Fällen, die vorher falsch liefen.
- Auto-Resolve beim Veröffentlichen beschrieben.

Agent-Prompt-Vorlage
- Fehler-Schnittstelle ergänzt, inklusive Hinweis auf "ignored": true, damit
  ein Agent bekannte Fehler nicht untersucht.

Alle in der Dokumentation genannten API-Pfade und Scopes wurden maschinell
gegen Routing und TokenManager abgeglichen.

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

docs/UPDATESERVICE_INTEGRATION_GUIDE.md

@@ -159,6 +159,75 @@ update-agent --project myapp --channel prod --action list
 
 ---
 
+## 4a. Prüf-Endpunkte (für eigene Anbindungen)
+
+Die Lese-Endpunkte sind bewusst **ohne Token** erreichbar, damit ausgelieferte
+Anwendungen ohne Anpassung weiter nach Updates suchen können. Sie liefern nur
+Release-Metadaten, die über die Download-URL ohnehin öffentlich sind.
+
+```bash
+GET /api/updateservice/v1/check?product=myapp&version=1.4.2&channel=prod
+```
+
+```json
+{
+  "status": "success",
+  "update_available": true,
+  "current_version": "1.4.2",
+  "latest_version": "1.4.3",
+  "is_critical": false,
+  "latest_release": {
+    "version": "1.4.3",
+    "download_url": "https://dc.mhdf.de/releases/myapp/prod/1.4.3/package.tar.gz",
+    "sha256_hash": "e3b0c442...",
+    "git_commit": "a21536f",
+    "size_bytes": 8412160,
+    "release_notes": "Behebt den Login-Fehler.",
+    "is_critical": 0
+  }
+}
+```
+
+Weitere Endpunkte:
+
+| Aufruf | Zweck |
+|---|---|
+| `GET .../latest?product=myapp&channel=prod` | Höchstes Release, unabhängig von der Client-Version |
+| `GET .../releases?product=myapp` | Alle Releases, nach Versionsordnung sortiert |
+
+### Versionsvergleich
+
+Der Vergleich folgt der semantischen Versionsordnung. Konkret bedeutet das:
+
+| Installiert | Verfügbar | Update? |
+|---|---|---|
+| `1.9.0` | `1.10.0` | ja — zweistellige Minor ist höher |
+| `1.10.0` | `1.9.0` | nein |
+| `1.0.0-rc.1` | `1.0.0` | ja — Release schlägt Vorabversion |
+| `1.0.0` | `1.0.0-rc.1` | nein |
+| `v1.4.2` | `v1.4.3` | ja — führendes `v` wird ignoriert |
+
+> Zuvor verglich der Server lexikografisch. `1.9.0` galt dadurch als neuer als
+> `1.10.0`, und Clients bekamen ein Downgrade als Update angeboten. Derselbe
+> Fehler steckte im .NET-Client bei `v`-präfigierten Versionen und ist dort
+> ebenfalls behoben.
+
+### Verknüpfung mit dem Bugtracker
+
+Beim Veröffentlichen schließen sich alle Bugtracker-Items, deren
+`resolved_in_build` der veröffentlichten Version entspricht, automatisch. Die
+Antwort nennt die Anzahl:
+
+```json
+{ "status": "success", "release_id": 12, "created": true, "auto_resolved": 3,
+  "message": "Release 1.4.3 (prod) für \"myapp\" veröffentlicht. 3 Bugtracker-Item(s) automatisch geschlossen." }
+```
+
+Damit schließt sich der Kreis: Ein Agent markiert einen Bug als „gelöst in
+v1.4.3", der Packager veröffentlicht v1.4.3, und das Item schließt sich selbst.
+
+---
+
 ## 5. LEMP Verzeichnisstruktur auf dem Server
 
 ```text