feat(tools): remote <ziel> <aktion> als Vordertuer zum Server (D77-Nachtrag)

Deployen, Log ansehen, Dienst schalten und fragen was laeuft waren vier
verschiedene Beschwoerungen, drei davon von Hand als ssh + systemctl. Jetzt:

  remote backend deploy|upload|setup|install-jdk|reset-password
  remote backend start|stop|restart|status|enable|disable
  remote backend log|info|documents|backup
  remote frontend deploy|preview|info
  remote ssh

Die Skripte unter scripts/ bleiben die Implementierung und einzeln aufrufbar;
tools/remote bringt nur mit, wofuer es bisher nichts gab. Wo ein Schalter
noetig war, kam er ins Skript statt ins Werkzeug: --unit-only in
deploy-backend.sh (sonst kennte eine zweite Stelle die Unit-Platzhalter) und
--dry-run in deploy-prod.sh, das die Befoerderung ausdruecklich mit abschaltet.

Neu ist die Sicherung: H2 haelt die Datei offen, also anhalten, holen, wieder
starten (gemessen ~8 s Auszeit) - und das Archiv lesen, bevor der Befehl es
behaelt. Gegenprobe von Hand: lokal ausgepackt, Backend mit --werkbaum.data-dir
dagegen gestartet, es liefert genau die Dokumente des Servers.

.envrc legt tools/ auf den PATH (direnv), 217 Plan-Knoten, 0 Warnungen.

backend/README.md

@@ -261,25 +261,33 @@ beim Start aus der IDE —, steht dort `unbekannt` statt eines Fehlers.
 
 ## Betrieb auf der stabilen Instanz
 
-`scripts/deploy-backend.sh` (im Repo-Wurzelordner) baut das Fat-Jar, legt es
-samt systemd-User-Unit ins Home des Servers und startet den Dienst neu;
-`scripts/install-jdk.sh` bringt einmalig ein JDK 21 dorthin. Der Dienst lauscht
-nur auf `127.0.0.1` — von außen kommt man über die Proxy-Regel in
-`scripts/prod.htaccess`, die der Frontend-Deploy mitspiegelt.
+`remote backend deploy` (aus dem Repo-Wurzelordner; ohne direnv
+`tools/remote …`) baut das Fat-Jar, legt es samt systemd-User-Unit ins Home des
+Servers und startet den Dienst neu; `remote backend install-jdk` bringt einmalig
+ein JDK 21 dorthin. Der Dienst lauscht nur auf `127.0.0.1` — von außen kommt man
+über die Proxy-Regel in `scripts/prod.htaccess`, die der Frontend-Deploy
+mitspiegelt.
+
+Dahinter stehen unverändert `scripts/deploy-backend.sh` und
+`scripts/install-jdk.sh`; `remote --help` zeigt alle Ziele und Aktionen.
 
 - **Speicher:** `-Xmx192m -Xms48m` plus Freiraum-Verhältnisse; gemessen rund
   174 MB RSS gegen 291 MB ohne Angaben. Nach einem GC leben ~45 MB. Zu wenig
   Luft? `BACKEND_XMX` in `.env`.
-- **Master-Passwort:** `scripts/reset-password.sh` fragt es verdeckt ab, hasht
-  es auf dem Server und prüft selbst nach, ob Hash und Passwort zueinander
-  passen. Gespeichert wird nur der Hash (`<BACKEND_DIR>/env`, Modus 600); ohne
-  ihn bleibt `GET /documents` gesperrt.
+- **Master-Passwort:** `remote backend reset-password` fragt es verdeckt ab,
+  hasht es auf dem Server und prüft selbst nach, ob Hash und Passwort
+  zueinander passen. Gespeichert wird nur der Hash (`<BACKEND_DIR>/env`, Modus
+  600); ohne ihn bleibt `GET /documents` gesperrt. Abrufen lässt sich die Liste
+  mit `remote backend documents`.
 - **Datenbank:** H2 im Dateimodus unter `<BACKEND_DIR>/data/`. Ein Deploy
   fasst das Verzeichnis nicht an (kein `--delete`). Umstieg auf das dort
   laufende PostgreSQL: JDBC-URL in der `application.yaml` tauschen und den
   Treiber ergänzen — Schema und Code bleiben.
-- **Nachsehen:** `systemctl --user status werkbaum-backend`,
-  `tail -f <BACKEND_DIR>/backend.log`.
+- **Sichern:** `remote backend backup`. H2 hält die Datei offen, solange der
+  Dienst läuft — gesichert wird deshalb mit kurzem Anhalten, und das Archiv
+  wird nach dem Herunterladen gelesen, bevor der Befehl es behält.
+- **Nachsehen:** `remote backend status`, `remote backend log`,
+  `remote backend info`.
 
 Begründungen: docs/DECISIONS.md D77 (und D76-Nachträge 1–3 zur Vermessung der
 Zielumgebung).