Remove Supabase

The database moved to a container of our own; the platform is gone.
This takes out what was left of it — and, where the leftovers were load
bearing, moves rather than deletes.

Moved, not deleted:

  supabase/migrations/  -> db/migrations/      the schema's source of truth
  supabase/build-org.ts -> scripts/build-org.ts
  lib/supabase/types.ts -> lib/types.ts        52 import sites repointed

The bookkeeping needed care. It lived in `supabase_migrations.schema_migrations`,
and simply renaming the schema would have left the runner facing an empty
table: it would have called all 67 migrations pending and replayed them
against a database that is long since current. So the runner now creates
`migrationen.schema_migrations` and, once, copies the old rows across —
guarded so a second run does nothing and a fresh database skips it entirely.
Only then does migration 20260907100000 drop the old schema.

Deleted: the CLI config, the seed, the historical schema/function dumps
(nothing read them), scripts/umzug-von-supabase.sh (the move is done), and
both Supabase packages plus the CLI. Nothing in the application imported
them — the build now succeeds with no environment variables at all, which
is the proof.

Integration tests: six of them signed in through Supabase Auth and asserted
against the anon key and the service role. That model is gone, so the tests
were not portable — they are deleted. session-context and
employee-status-filter already ran on pg and are untouched; om-reporting is
ported to a direct connection because it guards a real risk (the reporting
line rule exists twice, once in SQL and once in TypeScript).

CI: the integration job started a Supabase stack. It now runs a postgres
service, applies deploy/db-init and every migration to an empty database —
that was the valuable part, and it still holds — then checks that a second
run is a no-op, which is what proves the bookkeeping works.

Docs: security-review.md audited a service-role key, a cookie adapter and
auth.users, none of which exist. Restating findings about removed components
would suggest today's system had been reviewed; it has not. It now records
what was removed and says a fresh review is due. data-model.md was already
marked obsolete and described the pre-OM schema; azure-migration.md was a
plan for a route not taken. Both deleted.

Verified: npm ci, typecheck, lint, 445 tests, build — all clean without the
packages. Integration tests skip cleanly with no database. Migration SQL and
the runner are reviewed but NOT executed: no Docker here, and the old
instance no longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/migrate.mjs

@@ -1,23 +1,19 @@
 #!/usr/bin/env node
 // Spielt ausstehende Migrationen ein — und führt Buch darüber.
 //
-// ═══ Warum ein eigener Läufer und nicht `supabase db push` ═══
+// ═══ Warum ein eigener Läufer ═══
 //
 // Zwei Gründe, beide praktisch:
 //
-// 1. **Er braucht nur `pg`.** Das Paket liegt ohnehin im Projekt. Die
-//    Supabase-CLI müsste im Runner-Container bei jedem Lauf heruntergeladen
-//    werden, und ihre Version driftet unabhängig von diesem Repository.
-// 2. **Er tut genau eine Sache.** `db push` vergleicht Schemata, erzeugt
-//    Diffs und kann bei einer Abweichung mehr tun als nur die fehlenden
-//    Dateien anzuwenden. Beim automatischen Ausrollen ist „nur die fehlenden
-//    Dateien, in Reihenfolge, jede in ihrer eigenen Transaktion" genau das
-//    gewünschte Verhalten und nichts darüber hinaus.
+// 1. **Er braucht nur `pg`.** Das Paket liegt ohnehin im Projekt. Jedes
+//    zusätzliche Werkzeug müsste im Runner-Container bei jedem Lauf
+//    heruntergeladen werden, und seine Version driftet unabhängig von
+//    diesem Repository.
+// 2. **Er tut genau eine Sache.** Nur die fehlenden Dateien, in Reihenfolge,
+//    jede in ihrer eigenen Transaktion. Beim automatischen Ausrollen ist das
+//    genau das gewünschte Verhalten und nichts darüber hinaus.
 //
-// Die Buchführung liegt bewusst in `supabase_migrations.schema_migrations` —
-// derselben Tabelle in derselben Form, die die CLI benutzt. Damit bleibt
-// `supabase db push` weiterhin möglich, etwa von der Arbeitsstation aus: es
-// sieht dieselben Einträge und überspringt, was hier schon lief.
+// Die Buchführung liegt in `migrationen.schema_migrations`.
 //
 // ═══ Aufrufe ═══
 //
@@ -29,14 +25,14 @@
 // `--baseline` ist für den einen Fall gedacht, in dem eine Datenbank schon auf
 // dem Stand ist, die Buchführung aber fehlt — genau die Lage dieses Projekts
 // im August 2026, weil die Migrationen bis dahin von Hand eingespielt wurden.
-// Ohne diesen Schritt hielte der Läufer alle 65 für ausstehend und würde sie
+// Ohne diesen Schritt hielte der Läufer alle 67 für ausstehend und würde sie
 // gegen eine bereits migrierte Datenbank laufen lassen.
 
 import { readdirSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 import pg from "pg";
 
-const VERZEICHNIS = "supabase/migrations";
+const VERZEICHNIS = "db/migrations";
 
 const argumente = new Set(process.argv.slice(2));
 const nurZeigen = argumente.has("--dry-run");
@@ -45,13 +41,8 @@ const baseline = argumente.has("--baseline");
 // Der **direkte** Zugang als Verwalter — nicht DATABASE_URL.
 //
 // DATABASE_URL gehört der Anwendungsrolle, und die darf bewusst kein Schema
-// ändern; ausserdem zeigte sie bei Supabase auf den Transaktions-Pooler, der
-// mehrteilige Transaktionen nicht mitmacht.
-//
-// `SUPABASE_DB_URL` heisst nach dem Umzug auf einen eigenen Container nicht
-// mehr, was es ist — der Name bleibt als Rückfallebene, damit bestehende
-// .env-Dateien und Arbeitsstationen weiterlaufen.
-const verbindung = process.env.MIGRATE_DATABASE_URL || process.env.SUPABASE_DB_URL;
+// ändern.
+const verbindung = process.env.MIGRATE_DATABASE_URL;
 if (!verbindung) {
   console.error(
     "MIGRATE_DATABASE_URL fehlt. Erwartet wird der **direkte** Zugang als Verwalter,\n" +
@@ -79,17 +70,39 @@ const client = new pg.Client({
 await client.connect();
 
 try {
-  // Dieselbe Form, die die Supabase-CLI anlegt und erwartet.
-  await client.query(`create schema if not exists supabase_migrations`);
+  await client.query(`create schema if not exists migrationen`);
   await client.query(`
-    create table if not exists supabase_migrations.schema_migrations (
+    create table if not exists migrationen.schema_migrations (
       version text primary key,
       statements text[],
       name text
     )`);
 
+  // ── Einmalige Übernahme der alten Buchführung ──────────────────────
+  //
+  // Bis zum Umzug lagen die Einträge in `supabase_migrations.schema_migrations`.
+  // Ohne diese Übernahme fände der Läufer eine leere Tabelle vor, hielte alle
+  // 67 Migrationen für ausstehend und spielte sie gegen eine Datenbank ein,
+  // die längst auf dem Stand ist — mit einem Fehler beim ersten `create table`,
+  // das es schon gibt.
+  //
+  // Übernommen wird nur in eine noch **leere** Tabelle: ein zweiter Lauf tut
+  // nichts mehr. Auf einer frischen Datenbank gibt es die alte Tabelle nicht,
+  // dann fällt die Abfrage ganz weg.
+  const alteTabelle = (
+    await client.query(`select to_regclass('supabase_migrations.schema_migrations') is not null as da`)
+  ).rows[0]?.da;
+  if (alteTabelle) {
+    const { rowCount } = await client.query(`
+      insert into migrationen.schema_migrations (version, statements, name)
+      select version, statements, name from supabase_migrations.schema_migrations
+      where not exists (select 1 from migrationen.schema_migrations)
+      on conflict (version) do nothing`);
+    if (rowCount > 0) console.log(`${rowCount} Einträge aus der alten Buchführung übernommen.`);
+  }
+
   const verbucht = new Set(
-    (await client.query(`select version from supabase_migrations.schema_migrations`)).rows.map((r) => r.version)
+    (await client.query(`select version from migrationen.schema_migrations`)).rows.map((r) => r.version)
   );
 
   const ausstehend = dateien.filter((f) => !verbucht.has(zerlegen(f).version));
@@ -112,7 +125,7 @@ try {
       const { version, name } = zerlegen(datei);
       const inhalt = readFileSync(join(VERZEICHNIS, datei), "utf8");
       await client.query(
-        `insert into supabase_migrations.schema_migrations (version, statements, name)
+        `insert into migrationen.schema_migrations (version, statements, name)
          values ($1, $2, $3) on conflict (version) do nothing`,
         [version, [inhalt], name]
       );
@@ -135,7 +148,7 @@ try {
     try {
       await client.query(inhalt);
       await client.query(
-        `insert into supabase_migrations.schema_migrations (version, statements, name) values ($1, $2, $3)`,
+        `insert into migrationen.schema_migrations (version, statements, name) values ($1, $2, $3)`,
         [version, [inhalt], name]
       );
       await client.query("commit");