feat(bot): /whitelist status - der Bot fragt den Spielserver, wer was darf

Betreiber am 04.09.2026: "wenn wir das in den d4rkbot mit einbauen koennen
warum nicht".

DIE WHITELIST *IST* EINE DISCORD-ROLLE

d4rk_lib prueft bei jeder Verbindung live, ob die Person eine bestimmte Rolle
auf diesem Discord hat. "Jemanden auf die Whitelist setzen" heisst also: ihm
die Rolle geben. Das kann nur der Bot - der Spielserver hat keinen Zugriff auf
Discord.

Umgekehrt weiss nur der Spielserver, WER das darf. Deshalb fragt der Bot ihn,
statt Discord-Berechtigungen zu pruefen: sonst gaebe es zwei
Rechteverwaltungen, und die zweite erfuehre nie von einer Aenderung in der
Matrix. Dieselbe Regel wie ADR-0012 fuer das Panel setzt.

DIESER SCHRITT LIEST NUR

`/whitelist status @person` beantwortet drei Fragen an einem Ort: hat sie die
Rolle (fragt der Bot bei Discord), kennt der Spielserver ihr Konto, welche
Teamrolle hat sie bei uns.

Vergeben und Entziehen kommt als eigener Schritt - erst wenn dieser Weg
nachweislich durchlaeuft. Ein Schreibbefehl auf einem Kanal, den niemand
gemessen hat, ist ein Schreibbefehl ins Ungewisse.

DREI AUSGAENGE BEI DER RECHTEFRAGE, NICHT ZWEI

erlaubt, verboten, und "ich weiss es nicht". Der dritte ist der wichtige: ein
Bot, der bei einer Stoerung "verboten" sagt, sperrt das Team aus; einer, der
"erlaubt" sagt, oeffnet es fuer alle. Beides waere geraten.

WAS DER SPIELSERVER NICHT WEISS, BEHAUPTET ER AUCH NICHT: ob die Discord-Rolle
gesetzt ist, sieht er nur im Moment einer Verbindung. Der Bot fragt sie selbst
- er hat den Zugang.

DER ZWEITE HALTER DES GEHEIMNISSES

Bisher kannte nur das Adminpanel den Token fuer d4rk_web. Der Bot ist jetzt der
zweite. Beide sind eigene Container auf demselben Host und reden ueber das
interne Netz - aber es bleibt eine Verdopplung, und sie steht deshalb im Kopf
der Datei und in der .env.example, nicht in einer Fussnote.

Ohne SPIELSERVER_URL und SPIELSERVER_TOKEN tut /whitelist NICHTS und sagt es.
Ein Bot, der bei fehlender Konfiguration durchwinkt, waere schlimmer als einer,
der schweigt.

NOCH NICHT GEMESSEN: der Weg vom Bot zum Spielserver. Dafuer muessen die drei
Umgebungsvariablen im Container gesetzt sein, und das ist eine Handlung des
Betreibers. Die Serverseite (/person) ist dagegen gemessen: eine erfundene
Kennung liefert rolle=keine, kontoGelesen=true, konto=nil.

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

.env.example

@@ -72,3 +72,30 @@ GITEA_API_TOKEN=
 # als "yt-dlp fehlt" erscheinen -- nicht als Stille im Sprachkanal.
 # FFMPEG_PATH=ffmpeg
 # YTDLP_PATH=yt-dlp
+
+# ---------------------------------------------------------------------------
+# VERBINDUNG ZUM SPIELSERVER  (fuer /whitelist)
+# ---------------------------------------------------------------------------
+#
+# WOZU: der Bot fragt den Spielserver, WER die Whitelist verwalten darf. Die
+# Antwort steht in der Rechtematrix - derselben, die Adminmenue und Panel
+# benutzen. Wuerde der Bot stattdessen Discord-Berechtigungen pruefen, waere
+# das eine zweite Rechteverwaltung, die von einer Aenderung in der Matrix nie
+# erfaehrt.
+#
+# OHNE DIESE ZWEI WERTE TUT /whitelist NICHTS und sagt es. Ein Bot, der bei
+# fehlender Konfiguration durchwinkt, waere schlimmer als einer, der schweigt.
+#
+# Die Adresse ist die INTERNE: der Endpunkt liegt auf dem Spielport, und dieser
+# Weg soll nicht ueber das oeffentliche Netz laufen.
+# SPIELSERVER_URL=http://host.docker.internal:30130/d4rk_web
+#
+# DASSELBE GEHEIMNIS wie im Adminpanel (d4rk_web:geheimnis in web.cfg). Der Bot
+# ist damit der ZWEITE Halter - beide sind eigene Container auf demselben Host,
+# aber es bleibt eine Verdopplung und ist hier ausdruecklich benannt.
+# SPIELSERVER_TOKEN=
+#
+# Die Rolle, die den Zutritt oeffnet. Sie MUSS dieselbe sein, die der
+# Spielserver prueft (Convar d4rk_discord:role) - stimmen sie nicht ueberein,
+# zeigt /whitelist "hat die Rolle" fuer eine Rolle, die gar nichts oeffnet.
+# WHITELIST_ROLE_ID=