Token-Rechte vollstaendig dokumentiert

Die Angaben stammten aus der Zeit, als Nebula nur gelesen hat. Seit v1.7.0
legt es Issues an und schliesst sie - wer sich an README oder den Hinweis im
Verbindungsdialog hielt, bekam dabei einen 403.

Erhoben wurde es nicht aus dem Gedaechtnis, sondern aus dem Code: jeder
ausgehende Aufruf in lib/git/gitea.ts, github.ts und gitlab.ts, abgebildet
auf das noetige Recht.

Aufgeschluesselt nach Funktion statt nach System, damit erkennbar ist, was
sich weglassen laesst: der Abgleich allein kommt rein lesend aus, nur die
Issue-Anbindung schreibt.

**GitLab ist der unangenehme Fall.** Es kennt keinen schmalen Schreib-Scope
fuer Issues - dort geht nur "api", also alles, was das Konto darf. Das steht
jetzt ausdruecklich da, samt der Alternative: bei read_api bleiben und auf
die Issue-Anbindung verzichten. Der Abgleich laeuft dann vollstaendig, und
geschlossene Issues werden weiterhin erkannt, nur nicht zurueckgeschrieben.

Ebenfalls festgehalten, was Nebula *nicht* braucht: Schreibrechte auf Code,
Adminrechte, Rechte zum Anlegen von Webhooks. Letzteres ist der Grund, warum
der Haken von Hand eingetragen wird - so bleibt der Token davon frei.

Der Hinweis in lib/git/meta.ts steht direkt am Eingabefeld und ist die
Stelle, die tatsaechlich gelesen wird; er ist deshalb mitgezogen. Dazu ein
Waechter in meta.test.ts: jeder Provider muss in GitClient createIssue und
setIssueState koennen, folglich muss auch jeder Hinweis sagen, was das an
Rechten kostet. Genau diese Kopplung war hier gerissen.

Geprueft: 267 Unit-Tests (6 neue), 36 E2E-Tests, Hinweistext je System gegen
die laufende Anwendung gelesen, axe-core auf 375px und 1280px ohne
Beanstandung.

Refs #10

README.md

@@ -173,14 +173,8 @@ Nebula auffindbare Credentials nutzt.
 
 ## Git-Verbindung einrichten
 
-1. Im Git-System einen **Personal Access Token** mit Leserechten erzeugen:
-
-   | System | Scopes |
-   | --- | --- |
-   | GitHub | Fine-grained Token: *Contents: Read*, *Metadata: Read*, *Issues: Read*, *Pull requests: Read* |
-   | GitLab | `read_api` (alternativ `read_repository`) |
-   | Gitea / Forgejo | `repository:read`, `issue:read`, `user:read` |
-
+1. Im Git-System einen **Personal Access Token** erzeugen — mit den Rechten aus dem
+   Abschnitt [Welche Rechte der Token braucht](#welche-rechte-der-token-braucht).
 2. In Nebula unter **Git-Verbindungen → Verbindung hinzufügen** eintragen:
    System wählen, Basis-URL (z. B. `https://git.meine-firma.de`, ohne `/api`) und Token.
 3. Mit **Testen** prüfen — Nebula meldet den erkannten Benutzer zurück.
@@ -192,6 +186,47 @@ Nebula auffindbare Credentials nutzt.
 Der Snapshot bleibt in der Datenbank, das Dashboard funktioniert also auch offline.
 Ohne Token gehen nur öffentliche Repositories, mit strengem Rate-Limit.
 
+### Welche Rechte der Token braucht
+
+Nebula liest fast alles nur — geschrieben wird ausschließlich, wenn du eine Aufgabe als
+Issue anlegst oder abhakst. Deshalb lohnt es, zwei Fälle zu unterscheiden:
+
+**Fall A — nur Abgleich.** Branches, Tags, Commits, Releases, CI-Zustand, README,
+Heatmap, offene Issues und PRs anzeigen. Rein lesend.
+
+**Fall B — zusätzlich die Issue-Anbindung.** Eine Aufgabe als Issue anlegen; wird das
+Issue geschlossen, hakt Nebula die Aufgabe ab und schließt sie umgekehrt mit.
+
+| System | Fall A (nur lesen) | Fall B zusätzlich |
+| --- | --- | --- |
+| **GitHub** | Fine-grained Token: *Metadata: Read*, *Contents: Read*, *Issues: Read*, *Pull requests: Read*, *Actions: Read* | *Issues: **Read and write*** |
+| **GitLab** | `read_api` | `api` — **es gibt nichts dazwischen** |
+| **Gitea / Forgejo** | `read:repository`, `read:issue`, `read:user` | `write:issue` |
+
+Wozu die einzelnen Rechte gut sind:
+
+| Recht | Wofür |
+| --- | --- |
+| Repository lesen (`Contents`, `read:repository`) | Branches, Tags, Commits, Releases, Sprachen, README, Commit-Heatmap |
+| Issues lesen | Offene Issues auf der Projektseite, „Issues als Aufgaben übernehmen" |
+| Pull Requests lesen | Offene PRs auf der Projektseite |
+| Actions lesen (nur GitHub) | CI-Zustand des Default-Branch. Bei GitLab kommt er aus den Pipelines (`read_api`), bei Gitea aus dem Commit-Status (`read:repository`) |
+| Benutzer lesen | Nur für den Verbindungstest — Nebula meldet zurück, als wer der Token gilt |
+| Issues schreiben | Aufgabe als Issue anlegen, schließen, wieder öffnen |
+
+> **GitLab ist der unangenehme Fall.** Es kennt keinen schmalen Schreib-Scope für Issues:
+> `api` erlaubt alles, was dein Konto darf — auch Code ändern. Wenn dir das zu weit geht,
+> nimm `read_api` und verzichte auf die Issue-Anbindung. Der Abgleich funktioniert
+> vollständig, und geschlossene Issues werden trotzdem erkannt — nur eben nur gelesen.
+
+**Was Nebula *nicht* braucht:** Schreibrechte auf Code, Adminrechte, Rechte zum Anlegen
+von Webhooks. Den Haken für Webhooks trägst du selbst im Git-System ein — genau deshalb
+verlangt Nebula dafür kein zusätzliches Recht.
+
+**Im Zweifel klein anfangen.** Ein fehlendes Recht führt zu einem `403` mit dem Hinweis
+„Token hat nicht die noetigen Scopes"; die Meldung steht am Repository auf der
+Projektseite. Dann gezielt nachlegen, statt vorsorglich alles zu vergeben.
+
 ### Automatisch statt auf Knopfdruck
 
 Unter **Admin-Einstellungen → Automatischer Abgleich** lässt sich der Sync in den