feat(vorlagen): Versionierung, Unveraenderlichkeit und JSON-Austausch

Eine veroeffentlichte Vorlagen-Version ist fuer immer unveraenderlich — daran
haengt, dass ein archivierter Lauf in zehn Jahren noch genau die Schritte zeigt,
mit denen er gestartet wurde. Die Regel steht deshalb zweimal: im Service, der
die verstaendliche Meldung gibt, und in der Datenbank, die die Garantie gibt.
Vier Trigger fangen Schreibzugriffe ab, die nicht durch den Service kommen —
Migrationen, psql, der Seed und ab Phase 4 die Connectoren — und versperren den
Rueckweg nach ENTWURF, der alles andere ausgehebelt haette.

- Service: anlegen, Kopfdaten bearbeiten, Entwurf als tiefe Kopie der letzten
  veroeffentlichten Version, speichern, veroeffentlichen, verwerfen,
  duplizieren, archivieren
- Hoechstens ein Entwurf je Vorlage, durchgesetzt vom partiellen Index; zwei
  gleichzeitige Klicks auf „Bearbeiten“ bekommen denselben Entwurf statt eines
  Fehlers
- Optimistisches Sperren ueber geaendertAm: wer auf einem ueberholten Stand
  speichert, wird abgewiesen statt die Arbeit des anderen spurlos zu ersetzen
- JSON-Export und -Import samt Format-Dokumentation; der Export ist nachsichtig,
  der Import streng
- src/lib/validierung.ts als einzige Zod-Quelle mit deutschen Meldungen, per
  ESLint-Regel erzwungen

Der unabhaengige Review fand drei Blocker, alle an der Mandantengrenze: der
Suchfilter brachte ein zweites OR mit und ueberschrieb die Kundenbedingung,
Historie und Aufbau einer Version filterten gar nicht. Zu queries/vorlagen.ts
gab es keinen Test — jetzt gibt es tests/vorlagen-sicht.test.ts.

428 Tests gruen (vorher 336).

Schliesst #009

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/architektur.md

@@ -42,7 +42,7 @@ Der Auftrag nannte Auth.js. Beim Prüfen der Lage am 2026-09-24:
 
 - `next-auth` v5 steht auf `5.0.0-beta.32`, seit Jahren ohne GA
 - authjs.dev führt das Projekt im Wartungsmodus („The Auth.js project is now part of Better
-  Auth"), die Maintainer schreiben „no immediate plans for v5"
+  Auth"), die Maintainer schreiben „no immediate plans for v5“
 - `@auth/prisma-adapter` deklariert `@prisma/client` nur bis `>=6` — wir fahren Prisma 7
 
 Entschieden wurde deshalb der Eigenbau mit stabilen Bausteinen, wie in ProxLedger:
@@ -59,7 +59,7 @@ Cookie abgewiesen.
 
 Zwei Regeln tragen die Nachvollziehbarkeit:
 
-1. **Eine veröffentlichte `VorlagenVersion` wird nie verändert.** „Bearbeiten" erzeugt eine tiefe
+1. **Eine veröffentlichte `VorlagenVersion` wird nie verändert.** „Bearbeiten“ erzeugt eine tiefe
    Kopie als Entwurf. Ein Lauf auf Version 1 zeigt für immer die Schritte aus Version 1, auch
    wenn längst Version 5 veröffentlicht ist.
 2. **Ein archivierter Lauf ist schreibgeschützt.** Die Sperre sitzt in genau einer Funktion,
@@ -68,6 +68,13 @@ Zwei Regeln tragen die Nachvollziehbarkeit:
 
 Beides ist durch Tests abgedeckt, nicht durch Disziplin.
 
+Der Aufbau einer Version wird **als Ganzes** gespeichert, nicht Schritt für Schritt: der Editor
+hält den Baum im Speicher und sortiert per Drag & Drop, ein Teil-Update wäre dort ständig mit dem
+Sortieren im Streit. Dasselbe Zod-Schema (`src/lib/vorlagen-format.ts`) beschreibt den Entwurf im
+Editor, den JSON-Export und den Import — drei getrennte Schemata würden auseinanderlaufen, und der
+Import wäre der Ort, an dem das erst auffiele. Das Format ist in
+[`docs/vorlagen-format.md`](vorlagen-format.md) beschrieben.
+
 ## 5. Der Weg zu Phase 4 (Aktionen)
 
 Die in den Vorlagen vorbereiteten PowerShell-Befehle sind bewusst die **Vorstufe ausführbarer