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>

prisma/migrations/20260925054517_vorlagen_unveraenderlich/migration.sql

@@ -0,0 +1,94 @@
+-- ---------------------------------------------------------------------------
+-- HANDGESCHRIEBEN. Prisma hatte hier zusaetzlich sieben Loeschbefehle erzeugt:
+-- vier zusammengesetzte Fremdschluessel (Mandantengrenze) und drei
+-- Trigramm-Indizes (Archivsuche) aus der ersten Migration. Prisma kennt sie
+-- nicht, weil sie sich im Schema nicht ausdruecken lassen, und will sie deshalb
+-- bei jeder Migration entfernen. Die Loeschbefehle sind bewusst gestrichen.
+--
+-- tests/datenbankregeln.test.ts prueft, dass alle diese Objekte vorhanden sind –
+-- ein versehentlich stehengelassener Loeschbefehl faellt dort sofort auf.
+-- ---------------------------------------------------------------------------
+
+-- Stand des Entwurfs, gegen den der Editor beim Speichern prueft.
+ALTER TABLE "VorlagenVersion"
+  ADD COLUMN "geaendertAm" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
+
+-- ---------------------------------------------------------------------------
+-- Eine veroeffentlichte Version ist unveraenderlich.
+--
+-- Diese Regel traegt die Nachvollziehbarkeit des ganzen Archivs: ein Lauf zeigt
+-- auch in zehn Jahren genau die Schritte, die damals abgearbeitet wurden.
+-- Bisher stand sie nur in der Service-Schicht — Migrationen, psql, Skripte und
+-- ab Phase 4 die Connectoren schreiben daran vorbei. Deshalb steht sie jetzt
+-- auch hier.
+--
+-- TRUNCATE loest Zeilen-Trigger nicht aus; das Leeren der Testdatenbank bleibt
+-- also moeglich.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION laufzettel_version_unveraenderlich() RETURNS trigger AS $$
+DECLARE
+  betroffene_version TEXT;
+  aktueller_status TEXT;
+BEGIN
+  betroffene_version := COALESCE(NEW."versionId", OLD."versionId");
+  SELECT status::TEXT INTO aktueller_status
+  FROM "VorlagenVersion" WHERE id = betroffene_version;
+
+  IF aktueller_status = 'VEROEFFENTLICHT' THEN
+    RAISE EXCEPTION
+      'Version % ist veroeffentlicht und unveraenderlich (%).',
+      betroffene_version, TG_TABLE_NAME
+      USING ERRCODE = 'integrity_constraint_violation';
+  END IF;
+  RETURN COALESCE(NEW, OLD);
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER "VorlagenAbschnitt_unveraenderlich"
+  BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenAbschnitt"
+  FOR EACH ROW EXECUTE FUNCTION laufzettel_version_unveraenderlich();
+
+CREATE TRIGGER "VorlagenVariable_unveraenderlich"
+  BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenVariable"
+  FOR EACH ROW EXECUTE FUNCTION laufzettel_version_unveraenderlich();
+
+-- Schritte haengen ueber den Abschnitt an der Version, brauchen also den Umweg.
+CREATE OR REPLACE FUNCTION laufzettel_schritt_unveraenderlich() RETURNS trigger AS $$
+DECLARE
+  aktueller_status TEXT;
+BEGIN
+  SELECT v.status::TEXT INTO aktueller_status
+  FROM "VorlagenAbschnitt" a
+  JOIN "VorlagenVersion" v ON v.id = a."versionId"
+  WHERE a.id = COALESCE(NEW."abschnittId", OLD."abschnittId");
+
+  IF aktueller_status = 'VEROEFFENTLICHT' THEN
+    RAISE EXCEPTION
+      'Der Abschnitt gehoert zu einer veroeffentlichten Version und ist unveraenderlich.'
+      USING ERRCODE = 'integrity_constraint_violation';
+  END IF;
+  RETURN COALESCE(NEW, OLD);
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER "VorlagenSchritt_unveraenderlich"
+  BEFORE INSERT OR UPDATE OR DELETE ON "VorlagenSchritt"
+  FOR EACH ROW EXECUTE FUNCTION laufzettel_schritt_unveraenderlich();
+
+-- Der Weg zurueck von VEROEFFENTLICHT nach ENTWURF waere die Hintertuer, durch
+-- die sich alles Obige aushebeln liesse.
+CREATE OR REPLACE FUNCTION laufzettel_version_status_einbahn() RETURNS trigger AS $$
+BEGIN
+  IF OLD.status = 'VEROEFFENTLICHT' AND NEW.status <> 'VEROEFFENTLICHT' THEN
+    RAISE EXCEPTION
+      'Eine veroeffentlichte Version laesst sich nicht wieder zum Entwurf machen.'
+      USING ERRCODE = 'integrity_constraint_violation';
+  END IF;
+  RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER "VorlagenVersion_status_einbahn"
+  BEFORE UPDATE ON "VorlagenVersion"
+  FOR EACH ROW EXECUTE FUNCTION laufzettel_version_status_einbahn();