Deploymentcenter-Anbindung auf SDK 2.8.2 nachgezogen (#218)

Der Changelog seit 2.6.0 nennt sechs Fassungen, 16 action_items und fuenf
brechende Aenderungen. Davon trifft fast nichts diese Anwendung - und das
ist ein Befund, kein Versaeumnis:

- finding_status (brechend, 2.7.0): kein Aufrufer. Weder
  /api/supervisor/v1/observe noch /status werden hier angesprochen.
  Vorgemerkt fuer #528 Stufe 3 - wer den Manager baut, liest den
  Befundzustand von Anfang an aus diesem Feld.
- Nachpruefungs-Status awaiting_verification, in_verification,
  fix_insufficient (brechend, 2.6.1): Die Anwendung wertet
  bugtracker_items.status nirgends aus. Betrifft den Arbeitsablauf der
  Agenten, und der steht in CLAUDE.md bereits richtig beschrieben.
- Meldungen ohne project_slug (brechend, 2.8.1): BugtrackerClient und
  ErrorReporter schicken project_slug und build_version seit jeher mit.
- Leseweg ohne project_slug und schmales dc_roadmap (brechend, 2.8.1):
  betrifft den MCP-Adapter, nicht den Anwendungscode.

Geblieben ist die eine Zusage, die man nicht sieht, wenn man sie verletzt:
Seit 2.8.1 erbt ein Watchdog-Monitor das Projekt seines Ping-Tokens. Ohne
Bindung landen die Befunde im Scheinprojekt "default", und eine Abfrage
nach dem eigenen Projekt liefert fuer eine laufende, fleissig meldende
Instanz null Befunde - die Aufsicht sieht aus wie "nichts auffaellig". Das
ist genau die Falle, in die hier schon einmal Meldungen gelaufen sind.

Deshalb neu: TokenProvisioner.WhoAmIAsync gegen GET
/api/tokens/v1/whoami (SDK 2.7.1) und der Typ TokenIdentity mit
IsProjectBound. DeploymentcenterService fragt beim Start das eigene
Melde-Token, protokolliert das Projekt und warnt, wenn keines dransteht.
Bewusst nur eine Warnung: Monitoring, das bei unklarer Rechtelage gar nicht
erst anlaeuft, ist genau dann still, wenn man es braucht. Faellt die
Auskunft aus - aelterer Server, kein Netz -, bleibt es bei Debug.

Gemessen statt geraten: TokenProvisioner schickt keinen project_slug mit,
und ob der Server die Bindung vom Master-Token erbt, steht in keiner
Beschreibung, die vorliegt. Ein Sub-Token dafuer eigens auf dem
Produktivserver auszustellen waere zu viel Nebenwirkung gewesen; die erste
Instanz, die eines zieht, sagt es jetzt selbst ins Protokoll.

#176 ist erledigt und die Regel in CLAUDE.md gestrichen: dc_roadmap ohne
project_slug liefert jetzt das eigene Projekt (nachgemessen: 51 Eintraege,
alle clawddotnet). Wer projektuebergreifend lesen will, schickt
project_slug=all.

dc_link_project auf 2.8.2 gesetzt, CLAUDE.md-Zeile hochgesetzt.

Build ohne Warnungen, 717 Tests gruen, 8 uebersprungen.

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

CLAUDE.md

@@ -84,14 +84,14 @@ nicht: den Fehler ganz normal erneut melden — das Item wandert von selbst auf
 `unauthorized` → Token prüfen, nicht wiederholen. `already_claimed` → nächstes
 Item. `rate_limited` → Intervall verdoppeln, später erneut.
 
-### Zwei Stolperstellen, solange sie offen sind
+### Eine Stolperstelle, solange sie offen ist
 
-**`dc_roadmap` immer mit `project_slug: "clawddotnet"` aufrufen.** Ohne die
-Angabe liefert der Server die Roadmap *fremder* Projekte, obwohl die
-Werkzeugbeschreibung das eigene zusagt. Gemeldet als
-[#176](https://dc.mhdf.de/index.php#tab-bugtracker) unter `deploymentcenter`.
-Betrifft nur die lesenden Roadmap-Aufrufe; `dc_next_task` ist korrekt ans
-eigene Projekt gebunden.
+**#176 ist erledigt und die Regel dazu gestrichen.** Hier stand, `dc_roadmap`
+müsse immer mit `project_slug: "clawddotnet"` aufgerufen werden, weil der Server
+sonst fremde Projekte liefert. Seit SDK 2.8.1 gilt ohne Angabe das eigene
+Projekt — beim Lesen wie beim Melden. Nachgemessen am 2026-09-08: `dc_roadmap`
+ohne Slug liefert 51 Einträge, alle `clawddotnet`. Wer bewusst über alle
+Projekte lesen will, schickt jetzt ausdrücklich `project_slug: "all"`.
 
 **`roadmap_rank` gilt hier projektweit**, nicht je Bereich — die durchgehende
 Reihenfolge aus `docs/Roadmap.md` hängt daran. Wer einen Eintrag im WebUI
@@ -118,12 +118,28 @@ er liest `.mcp.json` beim Sitzungsbeginn. Eine neue Sitzung räumt das aus.
 `$DC_TOKEN` steht daneben in der Bash-Umgebung — damit lässt sich die REST-API
 direkt bedienen, wenn die Werkzeuge einmal ausfallen.
 
-Deploymentcenter-Anbindung: SDK 2.6.0, integriert am 2026-08-30.
-Aktuell ist 2.7.0; der Sprung ist ein eigenes Vorhaben und steht auf der
-Roadmap. Vor jeder Änderung an der Anbindung:
-`GET /api/updateservice/v1/changelog?since=2.6.0`, danach diese Zeile
+Deploymentcenter-Anbindung: **SDK 2.8.2**, nachgezogen am 2026-09-08 (#218).
+Vor jeder Änderung an der Anbindung:
+`GET /api/updateservice/v1/changelog?since=2.8.2`, danach diese Zeile
 hochsetzen und `dc_link_project` aufrufen.
 
+Was der Sprung 2.6.0 → 2.8.2 an dieser Anwendung geändert hat, ist wenig — und
+das ist ein Befund, kein Versäumnis: Von fünf brechenden Änderungen betrafen vier
+Wege, die diese Anwendung gar nicht geht (`?action=next`, Roadmap-Lesen,
+`/api/supervisor/v1/observe`). Der Meldepfad schickte `project_slug` und
+`build_version` bereits. Geblieben ist eine Zusage, die man nicht sieht, wenn man
+sie verletzt: Seit 2.8.1 erbt ein Watchdog-Monitor das Projekt seines
+Ping-Tokens; ohne Bindung landen die Befunde im Scheinprojekt „default", und
+`dc_findings` liefert für eine laufende, fleißig meldende Instanz **null
+Befunde** — die Aufsicht sieht aus wie „nichts auffällig". Die Anwendung fragt
+deshalb beim Start ihr eigenes Melde-Token über
+`GET /api/tokens/v1/whoami` (seit 2.7.1), protokolliert das Projekt und warnt,
+wenn keines dransteht.
+
+`finding_status` (brechend seit 2.7.0) ist noch niemandes Baustelle: Diese
+Anwendung ruft `observe` und `status` nicht auf. Wer den Instanzmanager baut
+(#528, Stufe 3), liest den Befundzustand von Anfang an aus diesem Feld.
+
 ## Weitere Handbücher
 
 | Dokument | Wofür |