docs(issues): #0074 - lucky locked, and why locked is not deactivated

Decision sorb. mas-cli locked the account and killed one OAuth and two browser
sessions, so signing in is no longer possible. deactivated_at stays empty though:
lucky now sits where scanner-test sits, not where @bojeledoggo does.

This MAS version's CLI has no deactivate-user - only lock/unlock. Full deactivation
runs through the admin API or Element Admin and therefore through an admin token,
which does not belong in a session. Locking takes the effect forward until sorb
makes it final with a click.

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

docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md

@@ -63,3 +63,21 @@ Einschränkung galt für dieses Konto also gar nicht.
 Damit sind von der Liste zwei Punkte erledigt (`@bojeledoggo` deaktiviert, `Boje`
 gelöscht). Offen bleiben die Testräume aus der Session 2026-07-27/28 und
 `clark`/`lucky`, beide in Synapse weiterhin aktiv.
+
+### `lucky` gesperrt 2026-08-18 (Entscheidung sorb)
+
+`mas-cli manage lock-user lucky` (MAS `locked_at = 2026-08-18 19:57`) plus
+`kill-sessions`: eine OAuth-2.0- und zwei Browser-Sessions beendet, Geräte-Sync
+angestoßen. Anmelden ist damit nicht mehr möglich.
+
+⚠️ **Gesperrt ist nicht deaktiviert.** `deactivated_at` ist leer — `lucky` steht
+jetzt wie `scanner-test`, nicht wie `@bojeledoggo` (dort ist `deactivated_at`
+gesetzt und Synapse führt `deactivated = 1`). Der Unterschied: Sperren ist
+reversibel (`unlock-user`), Deaktivieren räumt Profil, Geräte und Raum-Mitgliedschaften
+ab und ist es nicht.
+
+**Warum nur gesperrt:** Die hier laufende MAS-Version kennt im CLI kein
+`deactivate-user` (`mas-cli manage` bietet nur `lock-user`/`unlock-user`). Volle
+Deaktivierung läuft über die Admin-API bzw. Element Admin und damit über ein
+Admin-Token — das gehört nicht in eine Session. Wenn `lucky` endgültig weg soll,
+ist das ein Klick in Element Admin; das Sperren nimmt bis dahin die Wirkung vorweg.