fix(2.7.1): Auskuenfte, die stimmen - Fassung, Health, doctor, Ansicht

Der erste Durchlauf der Testinstanz hat neun Bugs zutage gefoerdert, und fast
alle waren dieselbe Sorte Fehler: eine Auskunft, die nicht stimmte.

Am folgenreichsten die Fassung. config/config.php fuehrte app.version als feste
Zeichenkette und stand seit 2.0.0 darauf, waehrend 2.7.0 lief - unbemerkt, weil
die Datei gitignored ist und in keinem Diff auftaucht. Zwei gemeldete Bugs sind
daran fehldiagnostiziert worden ("der Server ist zu alt"). src/bootstrap.php
leitet die Fassung jetzt aus "current" in public/docs/changelog.json ab.

Im Einzelnen:

- #346 Fassung aus dem Changelog statt aus der Konfiguration
- #60  /api/health ueberlebt eine leere Datenbank: eigener Check "schema",
       healthy=false mit Begruendung statt HTTP 500
- #54  dc-testkit doctor prueft Mindestfassung (semantisch) und Rechte, statt
       sie nur anzuzeigen - dafuer neu: GET /api/tokens/v1/whoami
- #53  dc-testkit.sh unter /testkit/ erreichbar (Route fehlte, der
       dokumentierte Bezugsweg hat nie funktioniert) und mit LF ausgeliefert
       (deploy.py/deploy_dev.py entfernen CR bei .sh/.bash beim Upload)
- #288 Filter und Formulare werfen nicht mehr aufs Dashboard zurueck: die
       offene Ansicht wandert bei GET als "view" in den Query-String, und die
       Filter loesen ueber requestSubmit() aus - form.submit() erzeugt kein
       submit-Ereignis, weshalb der zentrale Zuhoerer dort nie lief
- #347 /api/bugtracker/v1/roadmap auch ohne .php erreichbar
- #55  Fassungshinweis in TESTUMGEBUNG.md 4.6 (serverseitig war das mit 2.6.0
       bereits behoben)

Nicht geprueft: php -l. Auf dem Arbeitsplatz ist kein PHP installiert; die
Abnahme laeuft ueber die Testinstanz.

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

public/docs/bugtracker.md

@@ -70,6 +70,38 @@ Das zurückgegebene `sub_token` wird **nur einmal** ausgeliefert.
 Ist ein Token an ein Projekt gebunden, greifen alle Aufrufe automatisch nur
 auf dieses Projekt zu — ein Zugriff auf ein anderes liefert `403 project_forbidden`.
 
+### Was kann mein Token? (ab 2.7.1)
+
+```bash
+curl https://dc.mhdf.de/api/tokens/v1/whoami \
+  -H "Authorization: Bearer $DC_TOKEN"
+```
+
+```json
+{
+  "status": "success",
+  "name": "Werkbank polytrader",
+  "type": "master",
+  "owner_type": "dev_agent",
+  "is_workbench": true,
+  "project_slug": "polytrader",
+  "environment": "all",
+  "scopes": ["bugtracker:manage", "license:dev"],
+  "last_used_at": "2026-08-30 09:12:44",
+  "expires_at": null
+}
+```
+
+Gedacht für Werkzeuge, die ihre Voraussetzungen prüfen wollen, **bevor** sie
+etwas tun. Ohne diese Auskunft ließe sich ein Recht nur durch Ausprobieren
+feststellen — und das hat Nebenwirkungen: eine Probe auf `bugtracker:manage`
+übernähme ein Item, eine auf `license:dev` stellte einen Schlüssel aus.
+
+`is_workbench` ist der Wert, der über Fremdmeldungen entscheidet: nur ein Token
+der Besitzerart `dev_agent` darf in ein fremdes Projekt melden. Der
+Klartextwert des Tokens wird nicht ausgeliefert; ein widerrufenes oder
+abgelaufenes Token bekommt `401`.
+
 ---
 
 ## 2. Projekte finden