docs(git): jeden ausgehenden Aufruf einzeln mit seinem Recht belegen

Die Faelle A und B beantworteten die Frage auf Ebene der Scopes, nicht
auf Ebene der Aufrufe. Wer nachpruefen wollte, ob ein Recht wirklich
noetig ist, musste die drei Clients selbst lesen.

Jetzt steht in der README je System eine vollstaendige Tabelle: Aufruf,
Zweck, benoetigtes Recht. Die Zuordnung bei GitHub folgt der offiziellen
Berechtigungsuebersicht - dass /tags und /stats/commit_activity unter
Metadata fallen und nicht unter Contents, ist nicht zu erraten. Fuer
GitLab ist mit Quellenangabe belegt, dass es unterhalb von 'api' keinen
Schreibzugriff auf Issues gibt.

Ausserdem war offen, woher die Kommentare an den Issues stammen: Nebula
schreibt keine. Der Schreibzugriff besteht aus genau zwei Aufrufen. Ein
Test klopft dafuer die Clients ab - kaeme ein dritter dazu, wuerde die
Empfehlung 'nimm ein lesendes Token' still falsch, ohne dass jemand
einen Fehler saehe.

Der Hinweis am Eingabefeld nannte Actions nicht, obwohl der CI-Zustand
bei GitHub genau daran haengt.

Refs #10

FEATURES.md

@@ -487,8 +487,9 @@ Firmen-Gitea nebeneinander.
 
 #### Nötige Token-Rechte
 
-Nebula liest fast alles nur. Geschrieben wird ausschließlich beim Anlegen und Schließen
-von Issues (4.6) — wer darauf verzichtet, kommt mit einem rein lesenden Token aus.
+Nebula liest fast alles nur. Geschrieben wird an **genau zwei Stellen**: `POST …/issues`
+beim Anlegen und `PATCH`/`PUT …/issues/{nr}` beim Schließen oder Wiederöffnen (4.6). Wer
+darauf verzichtet, kommt mit einem rein lesenden Token aus.
 
 | System | Nur Abgleich | Zusätzlich für die Issue-Anbindung |
 | --- | --- | --- |
@@ -496,6 +497,10 @@ von Issues (4.6) — wer darauf verzichtet, kommt mit einem rein lesenden Token
 | GitLab | `read_api` | `api` |
 | Gitea / Forgejo | `read:repository`, `read:issue`, `read:user` | `write:issue` |
 
+Welcher Aufruf welches Recht verlangt, steht Zeile für Zeile in der
+[README](README.md#welche-rechte-der-token-braucht) — dort ist jeder ausgehende Aufruf
+der drei Clients aufgeführt.
+
 **GitLab kennt keinen schmalen Schreib-Scope.** `api` erlaubt alles, was das Konto darf,
 Code eingeschlossen. Wem das zu weit geht, bleibt bei `read_api`: der Abgleich läuft
 vollständig, geschlossene Issues werden weiterhin erkannt — nur schreibt Nebula dann
@@ -505,6 +510,11 @@ nicht zurück.
 Webhooks. Der Haken wird von Hand im Git-System eingetragen (4.7); das erspart dem Token
 genau die Administrationsrechte, die er sonst bräuchte.
 
+**Kommentare schreibt Nebula nie** — weder beim Anlegen noch beim Schließen. In den
+Rumpf des angelegten Issues wandert die Aufgabenbeschreibung plus eine Zeile Rückverweis
+auf das Projekt; danach bleibt der Text unangetastet. Was sonst an Kommentaren und
+Labels an einem Issue hängt, kommt aus der Weboberfläche oder von einem anderen Werkzeug.
+
 Ein fehlendes Recht endet in einem `403` mit „Token hat nicht die noetigen Scopes",
 sichtbar am Repository auf der Projektseite. Klein anfangen und gezielt nachlegen ist
 deshalb ohne Risiko.