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.

CLAUDE.md

@@ -9,6 +9,11 @@ Integrations-Backend.
 - `backend/` — Kotlin/Spring-Boot-Anwendung (Taiga-Integration, Persistenz).
   Eigene Regeln: backend/CLAUDE.md
 - `docs/` — Projektdokumente · `brand/` — Marke (brand/BRAND.md)
+- `tools/remote` — alles, was auf dem Server passiert, als Ziel und Aktion
+  (`remote backend deploy`, `remote frontend preview`, …; `remote --help`).
+  Die Arbeit machen weiterhin die Skripte unter `scripts/` — `remote` ist die
+  Vordertür davor. Braucht ein Skript einen neuen Schalter, kommt der **ins
+  Skript**, nicht ins Werkzeug (D77-Nachtrag).
 
 ## Verbindliche Referenzen
 - Sprachdefinition: @docs/SPEC.md — die Notation ist der gemeinsame Vertrag