feat(editor): Mehr-Fenster-Betrieb gebaut — Ablageschema v3, Tombstones, docsync, Sperre je Dokument (RFC 002, D94)

Kein Fenster schreibt mehr den Schlüssel eines anderen: Text, Meta und
frühere Stände liegen je Dokument unter eigenen Schlüsseln, der Index ist
nur noch Reihenfolge-Hinweis und löscht nie, Löschungen hinterlassen einen
Tombstone (7 Tage). Der Voll-Flush weicht dem Dirty-Flush. Damit sind
Befund 2 und 3 des RFC weg — verschiedene Dokumente in zwei Fenstern
kollidieren gar nicht mehr. docsync.js zieht Liste, Namen, Tombstones und
den Stände-Cache aus dem storage-Ereignis nach; am aktiven Dokument die
drei Fälle umbenannt / anderswo gelöscht (behalten, bis getippt wird) /
fremd geschrieben. Der modale D89-Dialog samt Präsenz-Kanal ist ersatzlos
raus; den einen Verlustfall — dasselbe nicht-`live:`-Dokument in beiden
Fenstern vorn — findet eine Sperre per Web Locks, und das zweite Fenster
bekommt drei Auswege statt „trotzdem fortfahren".

Im Browser mit zwei echten Tabs nachgemessen (RFC §10): Fälle 1–8 grün,
Fall 1 im Vor-v3-Build gegengeprüft und dort nachweislich rot. Fall 9
deckte auf, dass reviveGoneDoc() den Index-Hinweis nicht mitschrieb — ein
durch Tippen wiederbelebtes Dokument hing bis zum nächsten Flush allein an
seinen eigenen Schlüsseln und wäre bei einem Rückbau auf einen Build vor
v3 still verlorengegangen; behoben, Gegenprobe per Mutation gezogen.
Headless 666 Tests grün. Offen bleibt die Handarbeit: PWA neben Tab,
Firefox, Safari, ein Browser ohne Locks-API.

SPEC §9, D94, D89-Nachtrag, RFC (Status, §10, Revisionsgeschichte),
CHANGELOG und Plan-Knoten #ed.docs.windows nachgezogen.

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

docs/SPEC.md

@@ -952,14 +952,25 @@ anderen, ohne neu zu laden.
   10-Minuten-Takt sie wieder, und das Uhr-Menü zeigt sie als eigenen Abschnitt
   unter den Server-Meilensteinen. Siehe D89.
 
-**Ein zweites Werkbaum-Fenster desselben Browsers** — Tab, Fenster oder
-PWA — bekommt einen **modalen Dialog**, in beiden Fenstern, bis eines
-geschlossen ist: Beide schreiben in dieselbe Dokument-Ablage, der zuletzt
-speichernde überschreibt den anderen. Erkannt per Herzschlag
-(BroadcastChannel); der Dialog schließt sich **von selbst**, sobald das
-andere Fenster zu ist — es ist nichts zu bestätigen. „Trotzdem fortfahren"
-ist die Notluke und gilt je Fenster und Vorfall. Siehe D89 (und D84 für die
-zeilenlose Warnung, die daneben bestehen bleibt).
+**Ein zweites Werkbaum-Fenster desselben Browsers** — Tab, Fenster oder PWA
+— kollidiert nur noch am **selben nicht geteilten Dokument**: Text, Name und
+frühere Stände liegen je Dokument unter eigenen Schlüsseln, der Index löscht
+nie, und gelöschte Dokumente hinterlassen einen Tombstone. Verschiedene
+Dokumente in zwei Fenstern arbeiten daher still nebeneinander; ein
+anderswo angelegtes, umbenanntes oder gelöschtes Dokument zeigt sich im
+laufenden Fenster ohne Neuladen (storage-Ereignis). Für den einen
+Verlustfall hält jedes Fenster, solange ein nicht-`live:`-Dokument vorn
+ist, eine **Sperre** (Web Locks API) auf es — atomar, und sie fällt von
+selbst, wenn das Fenster schließt. Bekommt das zweite Fenster sie nicht,
+zeigt es einen Dialog mit drei Auswegen: anderes Dokument öffnen, hier nur
+ansehen (Textfeld schreibgeschützt, wird von selbst beschreibbar, sobald
+das andere Fenster loslässt) oder trotzdem hier bearbeiten — dann gewinnt
+der letzte Tastendruck, und die Warnung nennt das Dokument. `live:`
+-Dokumente werden nie gesperrt: Zwei Fenster sind zwei Live-Clients, der
+Server führt zusammen. Ohne Web Locks (file://, alte Browser) bleibt der
+storage-Rückfall: ein fremder Schreibzugriff am eigenen aktiven Dokument
+warnt, ohne Dialog. Siehe D94 (und D89 für die lokalen Sicherungen und den
+Wachhund).
 
 Siehe D76 (Protokoll und Begründung) und
 `backend/docs/live-editing-proposal.md`.