docs(issues): close #0084 - the token exists and is proven to work

sorb created the project access token with exactly what the job needs: Maintainer,
because main is protected with push=Maintainers, and write_repository only, because
the job pushes and never calls the API. Checked through the API without touching the
value.

Proven rather than assumed: a throwaway job pushed a ref with that token and removed
it again, leaving main untouched and no branch behind. So the value reaches the job -
protected variable on a protected branch - and it may write. The first real test is
the rotation on 2026-09-01.

Recorded as a future silent failure: the token expires 2027-08-19, and because the
job runs green while idle, nobody would notice until the next real rotation after
that date. Exactly the #0104 class, so it belongs in a calendar rather than in hope.

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

docs/issues/0084-gitops-51-ci-canonize-token-fuer-die-automatische-turn.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0084"
-status: next
+status: done
 created: 2026-08-02
 milestone: M1
 priority: medium
@@ -43,3 +43,39 @@ Der Rotations-CronJob läuft im Cluster und erreicht git.lab nicht; er pusht sei
 Bis dahin ist nichts kaputt: Ohne offene Rotation läuft der Job grün durch. Erst wenn am 01.09. wirklich rotiert wird und das Token fehlt, bricht er ab — laut und sichtbar, statt still das Falsche zu tun.
 
 Nebenbei aufgefallen: Der Branch `turn-secret-rotation-20260728-192656` liegt auf git.lab und Gitea, steckt aber längst in `main` — eine Karteileiche vom Juli. Kann weg, ist aber harmlos.
+
+## Erledigt 2026-08-19 — Token angelegt und nachweislich wirksam
+
+sorb hat den Project Access Token angelegt; die Eigenschaften stimmen mit dem überein,
+was der Job braucht (per API geprüft, ohne den Wert anzufassen):
+
+| | |
+|---|---|
+| Name | `canonize-rotation` |
+| Rolle | **Maintainer** — nötig, weil `main` mit `push = Maintainers` geschützt ist |
+| Scopes | **nur `write_repository`** — der Job pusht, er ruft keine API auf |
+| CI-Variable | `CANONIZE_TOKEN`, maskiert **und** geschützt |
+| Ablauf | **2027-08-19** |
+
+**Wirksamkeit belegt, nicht angenommen** (Pipeline 521, Wegwerf-Job, `main` unberührt):
+
+```
+Sichtbar: CANONIZE_TOKEN ist im Job gesetzt.
+SCHREIBEN OK: Zweig canonize-token-probe-521 angelegt.
+Aufgeraeumt: canonize-token-probe-521 wieder entfernt.
+```
+
+Der Job hat einen Wegwerf-Zweig angelegt und wieder gelöscht — damit ist gezeigt, dass
+der Wert im Job ankommt (geschützte Variable auf geschütztem Branch) **und** dass er
+schreiben darf. Der Prüf-Job ist danach wieder entfernt worden; es blieb kein Zweig
+liegen. Der erste echte Ernstfall ist die Rotation am **2026-09-01**.
+
+⚠️ **Ein Ablaufdatum ist ein stiller Ausfall in der Zukunft.** Am **2027-08-19** hört der
+Token auf zu gelten. Der Job läuft im Leerlauf trotzdem grün durch — auffallen würde es
+erst bei der nächsten echten Rotation danach, also frühestens am 2027-09-01. Genau die
+Klasse aus #0104. Gehört in den Kalender, nicht in die Hoffnung.
+
+**Zwei Fallen beim Prüfen**, hier notiert weil sie beim nächsten Mal Zeit kosten würden:
+Eine per API ausgelöste Pipeline hat die Quelle `api`, **nicht** `web` — die erste
+Fassung der Regel übersprang den Job deshalb wortlos. Und dieses Repo kennt keine Stage
+`pruefen` (das ist management); GitLab wies die Pipeline dafür komplett ab.