feat(frontend): "Auf den Server legen" im Dokumenten-Menue (D76-Nachtrag 8)

Bis hierher kam ein Plan nur per curl auf den Server — der Menueintrag war im
Konzept vorgesehen und fehlte. Jetzt legt der Knopf das aktive Dokument an,
schaltet dorthin um und schreibt den Link in die Adresszeile und in die
Zwischenablage. Die Adresszeile IST der Link: dort sucht man ihn, und ein
Neuladen fuehrt ins selbe Dokument zurueck.

Die Basis-Adresse ist die eigene Herkunft — produktiv liegt das Backend hinter
derselben Domain, wer nichts konfiguriert bekommt also das Richtige. Darueber
liegen ?server= (Entwicklung) und die Adresse des offenen Server-Dokuments.
Traegt nichts, wird gefragt.

Das lokale Dokument bleibt: Wer sein einziges Exemplar einem Server
anvertraut, soll es nicht im selben Zug verlieren. Dafuer nennt der Waehler
jetzt den Host neben Server-Dokumenten — im Test standen sonst zwei Eintraege
"Nur lokal" da, unterscheidbar nur am Tooltip. Und der Knopf verschwindet bei
Dokumenten, die schon auf einem Server liegen.

Geprueft im Browser gegen ein echtes Backend: Knopf sichtbar bei einem lokalen
Dokument, nach dem Klick steht ?live=... in der Adresszeile, das lokale
Dokument ist noch da, der Knopf verborgen — und eine getippte Zeile erreicht
den Server als Version 2.

523 Frontend-Tests (5 neue fuer serverBase/documentsUrl).

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

docs/CHANGELOG.md

@@ -23,6 +23,8 @@ reverse.
 - When two people change the same lines, a bar asks whose version should win — everything else the server merges by itself
 - The caret stays where you put it when someone else inserts lines above you
 - The backend can be deployed to a server: its own JDK, a systemd service, and Apache passing `/api/` on
+- "Put on the server" in the document menu turns a local plan into a shared one and puts the link in the address bar
+- A service endpoint `/api/v1/info` says which build is running — for deploys and monitoring
 
 ## 2026-08-25
 

docs/DECISIONS.md

@@ -6280,6 +6280,40 @@ alles Übrige zu sehen.
 **Offen bleibt** `PATCH /title` (und damit das Ereignis `RENAMED`), ein
 Eingabefeld für den Anzeigenamen und die Präsenz-Anzeige.
 
+**Nachtrag 8 — „Auf den Server legen" im Dokumenten-Menü (2026-08-26).** Der
+Haupttext sah den Menüeintrag vor („analog zu ‚Als Datei speichern'", D72), er
+fehlte aber: Auf den Server kam ein Plan nur per `curl`. Jetzt legt der Knopf
+das aktive Dokument an, schaltet dorthin um, schreibt den Link in die
+Adresszeile (`history.replaceState`) und in die Zwischenablage. Vier
+Festlegungen:
+
+**Die Basis-Adresse ist die eigene Herkunft.** Bei der produktiven
+Installation liegt das Backend hinter derselben Domain (`/api/…` per
+Proxy-Regel, D77) — wer nichts konfiguriert, bekommt also das Richtige.
+Darüber liegen zwei stärkere Quellen: der `?server=`-Parameter (für die
+Entwicklung, Editor auf 8137 und Backend auf 8080) und die Adresse des
+gerade offenen Server-Dokuments (wer dort sitzt und ein neues anlegt, meint
+denselben Server). Trägt nichts davon — auf `file://` gibt es keine
+brauchbare Herkunft —, wird gefragt und die Antwort gemerkt. Die Reihenfolge
+steht als reine Funktion in `live.js`, der Dialog nicht: Fragen ist keine
+entscheidbare Regel.
+
+**Das lokale Dokument bleibt.** Es zu löschen wäre die aufgeräumtere Geste
+und die riskantere: Wer sein einziges Exemplar einem Server anvertraut, soll
+es nicht im selben Zug verlieren.
+
+**Dafür braucht der Wähler eine Unterscheidung.** Das hochgeladene Dokument
+trägt denselben Namen wie das lokale — im Test standen prompt zwei Einträge
+„Nur lokal" da, unterscheidbar nur am Tooltip. Server-Dokumente nennen
+deshalb ihren **Host** neben dem Namen, zurückgenommen gesetzt; der Name
+bleibt die Hauptaussage.
+
+**Und der Knopf verschwindet, wo er nichts mehr zu tun hat.** Bei einem
+Dokument, das schon auf einem Server liegt, entstünde sonst ein zweites,
+gleichnamiges daneben. Erkannt an der id (`live:…`), nicht am laufenden
+Feed: Auch ein Server-Dokument, das gerade nicht das aktive ist, liegt
+bereits dort.
+
 ## D77 — Backend-Deploy: JDK im Home, systemd-User-Unit, Proxy in der `.htaccess`
 Das Frontend geht seit D16 per rsync auf die stabile Instanz. Das Backend
 braucht mehr als Dateien: eine Java-Laufzeit, einen dauerhaft laufenden Dienst

docs/examples/werkbaum.werkbaum

@@ -169,6 +169,7 @@
         | [?] #col.live.crdt: Text CRDT — the plan is plain text, so it fits (L)
         | [?] #col.live.ot: Operational transformation (XL)
       - [^] #col.live.ask: On a real overlap, ask whose version wins (S)
+      - [x] #col.live.upload: Put a local plan on the server, from the menu (S)
       - [?] #col.live.cursors: Cursors and who else is here (S)
       - [-] #col.live.ws: Transport over a websocket (S)  %% plain HTTP turned out to be enough
       - [-] #col.live.own: A merge algorithm of our own (XL)  %% solved problem, do not reinvent
@@ -986,6 +987,12 @@
   The other established answer, and the one Google Docs uses. More machinery
   for the same result.
 
+#col.live.upload
+  Without it the only way onto the server was a curl command. The local plan
+  stays where it is: whoever entrusts their only copy to a server should not
+  lose it in the act. The picker names the host beside a server document, so
+  the two entries are told apart.
+
 #col.live.cursors
   Seeing where the others are. A by-product of the merge layer rather than a
   feature in its own right.