test(tags): bleibt ein fremdes Etikett fremd?

internal/tags hatte null Tests, und die Rechtepruefung steckt dort nicht in
einer if-Zeile, sondern in WHERE-Klauseln. Ein Tippfehler darin faellt beim
Lesen nicht auf: Die Abfrage laeuft, sie liefert nur zu viel.

Fuenf Tests auf dieselbe Frage -- Liste, Umbenennen, Loeschen, Anhaengen an
die eigene Datei, und vor allem das Auflisten der **Dateien** unter einem
Etikett. Der letzte Weg gibt Dateinamen, Ordner und Groessen heraus; wer
dort eine fremde Etikett-ID erraet, saehe einen Ausschnitt aus fremden
Unterlagen. Dazu Gruppen: Mitglied ja, Nichtmitglied nein, und wer die
Gruppe verlaesst, verliert den Zugriff im selben Moment.

Gegen kaputten Code gegengeprueft: Eigentuemerpruefung aus FilesWithTag
entfernt -> "Bert sieht 1 fremde Dateien: Gehaltsabrechnung.pdf". Pruefung
in SetFieldsForFile ausgehebelt -> zwei Tests rot.

**Ein Verdacht erwies sich als falsch, und das ist der nuetzlichere
Ausgang:** List bietet Gruppen-Etiketten an, SetFieldsForFile vergleicht
gegen den Prinzipal der Datei -- sah nach einem Widerspruch aus. Ist keiner;
die Oberflaeche filtert bereits (TagDialog.tsx:69). Und die Ablehnung ist
nicht Foermlichkeit, sondern die tragende Absicherung: FilesWithTag prueft,
ob man das *Etikett* sehen darf, nicht die *Datei*. Das ist nur deshalb
harmlos, weil ein Etikett stets denselben Prinzipal hat wie die Dateien
darunter. Der Test haelt jetzt diesen Zusammenhang fest, nicht bloss eine
Fehlermeldung.

Nebenbei: tags hat zwei Fehlermarken fuer dieselbe Aussage (ErrNotFound und
ErrCorrespondentNotFound). Kein Fehler, aber eine Stolperstelle.

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

TESTING.md

@@ -269,6 +269,29 @@ es auffällt:
 Dazu: gelöschte Dateien werden nicht mehr genommen, ein erneuter Upload gibt
 eine neue Chance, und `Complete` schreibt Text und Auftragsende zusammen.
 
+### Etiketten und Absender: bleibt Fremdes fremd?
+
+    ./scripts/db-tests.sh ./internal/tags/
+
+Die Rechteprüfung steckt hier nicht in einer `if`-Zeile, sondern in
+WHERE-Klauseln. Ein Tippfehler darin fällt beim Lesen nicht auf: Die Abfrage
+läuft, sie liefert nur zu viel.
+
+Fünf Tests auf dieselbe Frage – Liste, Umbenennen, Löschen, Anhängen an die
+eigene Datei, und vor allem das **Auflisten der Dateien** unter einem Etikett.
+Der letzte Weg gibt Dateinamen, Ordner und Größen heraus.
+
+Dazu die Gruppen: Ein Mitglied sieht das Gruppen-Etikett, ein Nichtmitglied
+nicht, und wer die Gruppe verlässt, verliert den Zugriff im selben Moment.
+
+**Eine Absicherung, die wie eine Förmlichkeit aussieht:** Ein Gruppen-Etikett
+darf nicht an eine persönliche Datei. Der Grund steht nicht im Code, wo die
+Prüfung sitzt, sondern zwei Dateien weiter: `FilesWithTag` prüft, ob der
+Anfragende das *Etikett* sehen darf – **nicht**, ob er die *Datei* sehen darf.
+Harmlos ist das nur, weil ein Etikett stets denselben Prinzipal hat wie die
+Dateien darunter. Fiele die Prüfung weg, hinge an einem Gruppen-Etikett eine
+private Datei, und jedes Gruppenmitglied bekäme ihren Namen zu sehen.
+
 ### Was der Mutationsversuch gezeigt hat
 
 Die Tests wurden gegen **absichtlich kaputten Code** gegengeprüft – sonst weiß
@@ -283,6 +306,12 @@ Genau so verschwindet eine Entscheidung unbemerkt aus einer Anwendung. Dagegen
 steht jetzt ein Test, der die Zahl selbst festhält und sagt, wo die Begründung
 hingehört, falls sie sich ändert.
 
+Bei den Etiketten dasselbe Vorgehen, mit klarerem Ausgang: Eigentümerprüfung
+aus `FilesWithTag` entfernt → *„Bert sieht 1 fremde Dateien:
+Gehaltsabrechnung.pdf"*. Prüfung in `SetFieldsForFile` ausgehebelt → zwei Tests
+rot. Beide Absicherungen sind also wirklich abgedeckt und nicht bloß
+mitgelaufen.
+
 ## Notfall: Migration hängt fest ("Dirty database version")
 
 Betrifft jede künftige Migration, nicht nur eine bestimmte. Nachgestellt und