test: Ende-zu-Ende-Tests mit Playwright

13 Tests gegen die gebaute Anwendung mit eigener Datenbank auf Port 3111 -
also durch Middleware, Authentifizierung, Validierung und Datenbank hindurch.
Genau die Schicht, die Unit-Tests nicht erreichen. Laufzeit rund 20 Sekunden.

api.spec.ts prueft, was bisher nur von Hand geprueft war:
- Einrichtung sperrt sich nach dem ersten Konto
- ohne Anmeldung liefert jeder Endpunkt 401
- fremdes Origin und falscher Content-Type werden abgewiesen
- SSRF-Sperren greifen
- Datentrennung: ein zweites Konto bekommt auf fremde Projekte, Aufgaben und
  Adminwege durchgaengig 404 beziehungsweise 403, das Original bleibt
  unveraendert
- Aufgaben: Reihenfolge, abgeleiteter Fortschritt, untergeschobene IDs
- Export ohne Geheimnisse, Import je Strategie

ui.spec.ts geht den Weg eines Menschen: anmelden, Projekt anlegen, Aufgaben
anlegen und ziehen, suchen, abmelden. Das Ziehen wird nach einem Neuladen
erneut geprueft - sonst waere nur die Anzeige getestet, nicht das Speichern.

Zwei Vorkehrungen:
- global-setup.ts bricht ab, wenn der Datenbankname nicht "test" enthaelt,
  und zwar vor dem TRUNCATE. Der teuerste denkbare Fehler waere eine
  Testreihe, die die Produktivdaten leert.
- Playwright startet den Server selbst mit eigener DATABASE_URL und eigenem
  Port; eine laufende Instanz auf 3000 stoert nicht.

Beim Schreiben zeigte sich, dass synthetische Zieh-Gesten eine Pause vor dem
Loslassen brauchen - dnd-kit wertet die Bewegung in einem eigenen Frame aus
und faende sonst kein Ziel.

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

playwright.config.ts

@@ -0,0 +1,63 @@
+import { defineConfig } from "@playwright/test";
+
+/**
+ * Ende-zu-Ende-Tests gegen die echte Anwendung.
+ *
+ * Playwright startet den Produktionsserver selbst und richtet ihn auf eine
+ * eigene Datenbank. Der Port ist bewusst ein anderer als 3000 und 3100,
+ * damit eine laufende Instanz nicht stoert.
+ *
+ * Voraussetzung: ein Bau (`npm run build`) und eine leere Datenbank, deren
+ * Name "test" enthaelt – siehe global-setup.ts. Beides erledigt
+ * `npm run test:e2e`.
+ */
+
+const PORT = Number(process.env.E2E_PORT ?? 3111);
+const BASE_URL = `http://localhost:${PORT}`;
+
+const DATABASE_URL =
+  process.env.E2E_DATABASE_URL ??
+  "postgresql://nebula:nebula@localhost:5432/nebula_e2e_test?schema=public";
+
+export default defineConfig({
+  testDir: "./e2e",
+  // Die Tests teilen sich eine Datenbank, deshalb nacheinander.
+  fullyParallel: false,
+  workers: 1,
+  forbidOnly: Boolean(process.env.CI),
+  retries: process.env.CI ? 1 : 0,
+  reporter: process.env.CI ? [["list"], ["html", { open: "never" }]] : [["list"]],
+  timeout: 60_000,
+  expect: { timeout: 10_000 },
+
+  globalSetup: "./e2e/global-setup.ts",
+
+  use: {
+    baseURL: BASE_URL,
+    locale: "de-DE",
+    timezoneId: "Europe/Berlin",
+    trace: "retain-on-failure",
+    screenshot: "only-on-failure",
+    // Oertlich der installierte Chrome, damit kein Browser geladen werden
+    // muss. In CI gibt es keinen – dort das mitgelieferte Chromium
+    // (siehe "playwright install chromium" im Arbeitsablauf).
+    ...(process.env.CI ? {} : { channel: "chrome" as const }),
+  },
+
+  webServer: {
+    command: "npm start",
+    url: `${BASE_URL}/api/health`,
+    reuseExistingServer: false,
+    timeout: 120_000,
+    stdout: "pipe",
+    stderr: "pipe",
+    env: {
+      DATABASE_URL,
+      PORT: String(PORT),
+      APP_URL: BASE_URL,
+      NODE_ENV: "production",
+      // Fester Schluessel, damit Laeufe vergleichbar bleiben.
+      APP_SECRET: "e2e-test-secret-nur-fuer-die-testlaeufe-1234567890",
+    },
+  },
+});