docs: Feed nur im sichtbaren Tab (D76-Nachtrag 1)

Der Zielserver bietet kein HTTP/2, also gilt das Browser-Limit von sechs
Verbindungen je Herkunft - ein dauerhaft offener Long-Poll je Tab engt bei
mehreren Tabs alles andere ein. Der Feed schliesst deshalb bei
visibilitychange und holt beim Zurueckkommen mit dem eigenen since nach.
Ein Hintergrund-Tab braucht keinen Live-Feed; das spart nebenbei
Server-Worker und Akku. Ein SharedWorker waere sauberer, ist aber eine eigene
Baustelle fuer ein Problem, das die einfache Loesung praktisch beseitigt.

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

docs/DECISIONS.md

@@ -5927,8 +5927,15 @@ Antwort am Ende des Wartens.
 
 Drei Befunde bleiben als Arbeit stehen. **Kein HTTP/2** — damit gilt das
 Browser-Limit von sechs Verbindungen je Herkunft, und mehrere Tabs derselben
-Person binden je eine dauerhaft; zu beheben serverseitig oder clientseitig
-über einen SharedWorker, der allen Tabs eine gemeinsame Feed-Verbindung gibt.
+Person binden je eine dauerhaft. **Entschieden: Der Feed läuft nur im
+sichtbaren Tab** — bei `visibilitychange` schließen, beim Zurückkommen einmal
+mit dem eigenen `since` nachholen. Ein Hintergrund-Tab braucht keinen
+Live-Feed, niemand schaut hin, und ein einziger Request holt den Rückstand;
+das spart nebenbei Server-Worker und Akku. Erwogen und verworfen war ein
+**SharedWorker**, der allen Tabs eine gemeinsame Verbindung gibt — technisch
+sauberer und auch für Hintergrund-Tabs aktuell, aber eine eigene Baustelle
+mit Nachrichtenprotokoll, Lebenszyklus und Rückfallpfad, für ein Problem, das
+die einfache Lösung praktisch ganz beseitigt.
 **Nur Java 17** installiert, während `build.gradle.kts`
 `JavaLanguageVersion.of(21)` verlangt. Und der **Weg vom Apache zum Backend
 ist ungeklärt**: `ProxyPass` ist in `.htaccess` nicht zulässig,