docs: Werks-Token und Vertrauensgrenze in der README

Die README behauptete noch, das Token stehe einmalig auf der seriellen
Konsole - seit der Umstellung auf das Werks-Token wie ninlight falsch.

Dazu die Vertrauensgrenze, die bisher nur in der Firmware stand: wer im
selben WLAN ist und das oeffentliche Token kennt, kann das Geraet steuern und
Firmware aufspielen. Bewusst so, wie bei ninlight. Eine automatische
Sicherheitspruefung hatte die Vorbelegung im Dialog beanstandet - die
Begruendung gehoert deshalb auch hierher, nicht nur in die Firmware.

README.md

@@ -22,9 +22,23 @@ dort etwas korrigiert, findet es hier an derselben Stelle.
 ## Einrichtung
 
 Das Gerät meldet sich per mDNS und wird von Home Assistant vorgeschlagen.
-Nötig ist nur das **API-Token** — es steht einmalig auf der seriellen Konsole,
-wenn das Gerät zum ersten Mal startet. Ein Werksreset erzeugt ein neues; dann
-fragt Home Assistant von selbst nach.
+Nötig ist nur das **API-Token**. Im Auslieferungszustand und nach jedem
+Werksreset antwortet das Gerät mit dem öffentlichen Werks-Token
+`aabbccddeeff0011223344` — dasselbe wie bei ninlight —, und der Dialog belegt
+es vor. Wer ein eigenes gesetzt hat, trägt es dort ein.
+
+### Vertrauensgrenze
+
+Das Werks-Token steht öffentlich im Repo. **Wer im selben WLAN ist und es
+kennt, kann das Gerät steuern, Einstellungen ändern und Firmware aufspielen.**
+Das ist eine bewusste Entscheidung, gleich wie bei ninlight: Ziel ist, die
+Geräte einfach nutzbar zu halten, nicht ein gehärtetes Sicherheitsmodell.
+
+Wer das nicht will, setzt ein eigenes Token — über die Firmware-API mit
+`PUT system/settings {"type": "token", "token": "..."}` — und trägt es hier
+ein. Für einen gehärteten Bau lässt sich das Werks-Token in der Firmware auch
+ganz abschalten (`NL_DEFAULT_TOKEN` leer); dann würfelt das Gerät beim ersten
+Start und gibt das Token einmalig seriell aus.
 
 Ohne mDNS geht es auch von Hand über Adresse und Token.