docs(issues): close #0043, record the coverage map for #0044

#0043: the case-insensitive username policy is live and verified end to end —
present in the ConfigMap, mounted in the worker, applied by authentik on its own,
and bound to the prompt stage. It reads only prompt_data, since the stage runs
anonymously and that is exactly what the previous system policies died on.

#0044 turns out to be largely solved already, which the issue could not know: the
ESS chart hangs config and secret hashes on the pod template as labels, so MAS and
the other chart components do roll out on change, and coturn has its own annotation
bump driven by the rotation job. What remains are three services whose secrets
change rarely and deliberately — recommending against adding a controller for that.

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

STATUS.md

@@ -2,9 +2,9 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (24 open, 23 closed)
+## Issues (23 open, 24 closed)
 
-Verteilung: M1 6 · M2 13 · M4 2 · M5 3
+Verteilung: M1 6 · M2 13 · M4 2 · M5 2
 
 | Issue | Status | Meilenstein | Priorität | Title |
 |---|---|---|---|---|
@@ -27,7 +27,6 @@ Verteilung: M1 6 · M2 13 · M4 2 · M5 3
 | [0034](docs/issues/0034-cfgmon-11-gitea-ci-rueckbau-abschliessen.md) | open | M2 | medium | CFGMON-11 — Gitea-CI-Rückbau abschließen (sicher rückbaubare Schritte) |
 | [0040](docs/issues/0040-neckbeard-rueckmeldungen-einreichen.md) | open | M2 | low | neckbeard-Rückmeldungen aus dem Feldtest einreichen |
 | [0042](docs/issues/0042-migration-in-betrieb-nehmen-push-spiegel-schedule.md) | open | M2 | high | Migration in Betrieb nehmen: Push, erster Spiegel-Lauf, CI-Schedule |
-| [0043](docs/issues/0043-invitation-flow-eindeutigkeit-case-insensitiv.md) | open | M5 | medium | Invitation-Flow: case-insensitive Eindeutigkeitsprüfung im Prompt-Stage |
 | [0044](docs/issues/0044-sops-secret-aenderung-startet-dienst-nicht-neu.md) | open | M5 | low | SOPS-Values-Secret-Änderung startet den konsumierenden Dienst nicht neu |
 | [0045](docs/issues/0045-report-event-kein-kontaktweg-fuer-melder.md) | open | M1 | low | Inhalts-Meldung führt ins Leere: kein Kontaktweg für Melder |
 | [0051](docs/issues/0051-cve-remediation-pass.md) | open | M5 | high | CVE-Remediation-Pass: Schwachstellen-Report abarbeiten |

docs/issues/0043-invitation-flow-eindeutigkeit-case-insensitiv.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0043"
-status: open
+status: done
 created: 2026-08-11
 milestone: M5
 priority: medium
@@ -36,3 +36,32 @@ und deckt Kollisionen mit bestehenden Matrix-Konten nicht ab.
 
 Rein defensive Ergänzung / UX — der Übernahme-Vektor selbst ist bereits zu.
 Deshalb M5 (Härtung, nicht Reparatur) und `priority: medium`.
+
+## Erledigt 2026-08-15
+
+Expression-Policy **`matrix-username-eindeutig-ci`** im Blueprint ergänzt und an die
+Prompt-Stage des `matrix-invitation`-Flows gebunden (gitops `afc4ad3`). Sie prüft
+`prompt_data.username` per `username__iexact` gegen bestehende Konten und weist eine
+Kollision mit sichtbarer Meldung ab — dort, wo der Fehler entsteht, statt später beim Login.
+
+⚠️ **Bewusst ohne Zugriff auf `request.user`.** Die Stage läuft im **anonymen**
+Enrollment-Kontext; genau daran waren die früher hier hängenden 16 System-Policies gescheitert
+(`'AnonymousUser' object has no attribute 'group_attributes'`). Gelesen wird ausschließlich
+`prompt_data`. Der Kommentar im Blueprint hält das fest, damit die Falle nicht wiederkehrt.
+
+**Verifiziert am laufenden System** (nicht nur „Blueprint gepusht"):
+
+| Prüfung | Ergebnis |
+|---|---|
+| ConfigMap im Cluster | Policy enthalten |
+| Datei im Worker-Pod gemountet | Policy enthalten |
+| Blueprint von Authentik angewandt | Policy `matrix-username-eindeutig-ci` in der DB vorhanden |
+| Bindung an die Stage | `matrix-invitation-prompt → matrix-username-eindeutig-ci` |
+
+Authentik hat den Blueprint **selbstständig** übernommen — kein Neustart nötig.
+
+**Grenze, die bleibt:** Geprüft wird gegen **Authentik**-Konten. Ein reines Matrix-Konto ohne
+Authentik-Entsprechung fällt weiterhin erst bei MAS auf (`on_conflict: fail`, ADR-0011) — das
+bleibt die harte Sicherheitsgrenze, diese Policy ist die freundliche davor. Eine Prüfung gegen
+Synapse aus einer Policy heraus hieße Netzwerkaufruf plus Credentials im Ausdruck; das wäre
+schlechter als der bestehende Zweiklang.

docs/issues/0044-sops-secret-aenderung-startet-dienst-nicht-neu.md

@@ -39,3 +39,51 @@ Verifikations-Regel — leicht zu vergessen.
 
 Automatisiert nur den bereits in ADR-0011 vorgeschriebenen manuellen Schritt —
 daher `priority: low`. M5, weil die Fähigkeit (Auto-Reload) neu ist, nicht kaputt.
+
+## Untersuchung 2026-08-15 — die Abdeckung ist deutlich besser als angenommen
+
+Vor dem Einbau eines Reloaders geprüft, wo die Lücke **tatsächlich** klafft. Ergebnis: der im
+Issue beschriebene Fall (MAS) ist bereits abgedeckt, und zwar von der Chart selbst.
+
+**MAS ist abgedeckt — verifiziert am laufenden Deployment.** Die ESS-Chart hängt Prüfsummen
+als **Labels** ans Pod-Template (`templates/matrix-authentication-service/deployment.yaml`):
+
+```
+k8s.element.io/matrix-authentication-service-config-hash: sha1sum(configmap-data)
+k8s.element.io/matrix-authentication-service-secret-hash: sha1sum(secret-data)
+```
+
+Ein geändertes Label ändert das Pod-Template — Kubernetes rollt also von selbst aus. Live
+vorhanden (drei Hash-Labels am MAS-Deployment). Und der HelmRelease steht auf `interval: 1m`,
+Flux liest `valuesFrom` also jede Minute neu ein und rendert bei Änderung neu.
+
+**Damit ist die Ursachenannahme des Issues zu korrigieren:** Der Mechanismus fehlte nicht.
+Wahrscheinlicher ist, dass beim ADR-0011-Vorfall innerhalb des ersten Reconcile-Fensters
+geprüft wurde — „committet ≠ deployed" stimmt, aber die Lücke war **zeitlich**, nicht
+strukturell. Das ändert nichts an der Richtigkeit der ADR-0011-Regel (nach einem
+Sicherheits-Fix aktiv verifizieren), wohl aber an der Diagnose.
+
+**Abdeckung im Überblick** (Hash-Labels am Pod-Template gezählt):
+
+| Abgedeckt | wodurch |
+|---|---|
+| MAS (3), element-web (2), haproxy (3), matrix-rtc (1–2) | ESS-Chart-Hash-Labels |
+| coturn + Synapse (TURN-Secret) | eigener Mechanismus: der Rotations-CronJob hebt `rotated-at`/Checksum-Annotationen, der Merge startet beide Verbraucher neu (#38) |
+
+| Nicht abgedeckt | konsumiertes Secret |
+|---|---|
+| `draupnir` | `draupnir-config` |
+| `wikijs` | `wikijs-postgres-secret` |
+| `concierge-bot` | `concierge-credentials` |
+
+**Bewertung.** Übrig bleiben drei Dienste mit Secrets, die sich **selten und stets absichtlich**
+ändern — anders als das monatlich rotierende TURN-Secret, das genau deshalb bereits einen
+eigenen Trigger hat. Ein zusätzlicher Controller (stakater/Reloader) bräuchte Rechte, Deployments
+zu patchen, und würde eine Dauerkomponente für ein Risiko einführen, das bei den wirklich
+bewegten Secrets bereits gelöst ist.
+
+**Empfehlung: nicht einbauen**, sondern diese Abdeckungskarte als Ergebnis festhalten und die
+ADR-0011-Regel (aktiv verifizieren) für die drei Nachzügler gelten lassen. Wer anderer Meinung
+ist, hat mit Reloader einen sauberen Weg — die Chart erlaubt Annotationen je Komponente
+(`matrixAuthenticationService.annotations`, schema-geprüft), sie landen am Deployment **und** am
+Pod-Template.