Talk to PostgreSQL directly, and let the pooled connection forget

Zweiter Schritt weg von Supabase. Sämtliche 49 Lesezugriffe und alle
Mutationen laufen jetzt über lib/db statt über die REST-Schicht: Kysely auf
einem pg-Pool, jede Abfrage in einer Transaktion, in der zuerst
app.user_id gesetzt wird. Die Anmeldung hängt noch an GoTrue — sie liefert
die Kennung, die in withUser() geht. Damit war der Umbau in zwei Hälften
teilbar und die Anwendung durchgehend lauffähig.

Was dabei ersatzlos verschwindet:

  - fetchAllRows. Es gab die Funktion nur, weil PostgREST jede Antwort bei
    1000 Zeilen still abschneidet und ein Bericht dann leise falsch war.
    Am direkten Zugang ist eine Abfrage eine Abfrage.
  - sanitizeIlikeTerm samt Test. Sie entschärfte Zeichen, die in der
    Filtersyntax strukturelle Bedeutung hatten; jetzt wird der Suchbegriff
    als Parameter gebunden und ein Komma ist ein Komma. Die Lücke ist nicht
    abgesichert, sondern weg.
  - lib/supabase/admin.ts. Der Dienstschlüssel, der RLS aushebelte, hatte
    genau einen Aufrufer — den nächtlichen Lauf. Der benutzt jetzt dieselbe
    Rolle ohne BYPASSRLS und ruft eine SECURITY-DEFINER-Funktion auf, die
    selbst prüft, was sie tut. Es gibt keinen privilegierten Zugang mehr.

Nebenbei besser geworden, weil der direkte Zugang es erlaubt:

  - Eine Seite ist eine Transaktion. Das Layout etwa liest Profil,
    Planstellen, Standorte, Entwürfe und Notizen auf einem einheitlichen
    Lesestand statt in fünf unabhängigen Anfragen.
  - Der Bereichsfilter der Mitarbeiterliste ist ein EXISTS statt einer
    eingebetteten Ressource mit !inner — eine Person mit mehreren
    Zuordnungen über die Zeit erschien dort mehrfach.
  - Seitenweise Listen sortieren zusätzlich nach id. Bei gleichem Nachnamen
    oder gleichem Zeitstempel war die Reihenfolge vorher unbestimmt, und
    dieselbe Zeile konnte auf zwei Seiten erscheinen oder auf keiner.
  - Angehörige werden in der Datenbank gezählt statt alle Zeilen zu holen.
  - Namen an Ereigniszeilen kommen aus einem Join statt aus einem
    Nachschlag, der ausserhalb der Transaktion lag.

Der Statusfilter ist mitgezogen: dieselbe Regel wie deriveStatusAsOf,
Klausel für Klausel, jetzt als Kysely-Ausdruck. Der Integrationstest, der
beide über den gesamten Bestand vergleicht, läuft weiter — mit eigener
Verbindung, denn geprüft wird die Bedingung, nicht die Berechtigung.

Zwei Fehler auf dem Weg, beide vom Typprüfer gefangen: apply_due_pending_
changes() nimmt kein Argument, wurde von callFunction aber mit jsonb
aufgerufen — Postgres hätte keine passende Signatur gefunden. Und der
Sicherheitstest lädt jetzt Module mit `import "server-only"`, was ausserhalb
der Server-Übersetzung wirft.

Typecheck, Lint, Build und 180 Tests sind grün. Ungeprüft bleibt der Lauf
gegen eine echte Datenbank — dafür fehlt eine DATABASE_URL.

lib/employee-status-filter.ts

@@ -1,3 +1,5 @@
+import type { Expression, ExpressionBuilder, SqlBool } from "kysely";
+import type { Schema } from "./db/schema";
 import type { EmploymentStatus } from "./supabase/types";
 
 // The SQL counterpart of deriveStatusAsOf() in lib/reports.ts.
@@ -19,58 +21,59 @@ import type { EmploymentStatus } from "./supabase/types";
 // tests/integration/employee-status-filter.test.ts asserts the two agree
 // against a real database, which is the only place that can prove it.
 
-type Filterable = {
-  gt: (column: string, value: string) => Filterable;
-  lte: (column: string, value: string) => Filterable;
-  gte: (column: string, value: string) => Filterable;
-  or: (filters: string) => Filterable;
-  is: (column: string, value: null) => Filterable;
-  not: (column: string, operator: string, value: null) => Filterable;
-};
+type Eb = ExpressionBuilder<Schema, "employees">;
 
 /** True once the person has started and has not left yet. */
-function employed<Q extends Filterable>(query: Q, asOf: string): Q {
-  return query.lte("entry_date", asOf).or(`exit_date.is.null,exit_date.gt.${asOf}`) as Q;
+function employed(eb: Eb, asOf: string): Expression<SqlBool> {
+  return eb.and([eb("entry_date", "<=", asOf), eb.or([eb("exit_date", "is", null), eb("exit_date", ">", asOf)])]);
 }
 
 /**
- * Narrows a PostgREST query to the employees whose *derived* status on
- * `asOf` is one of `statuses`. Only the combinations the UI offers are
- * supported; anything else is left unfiltered rather than silently applying
- * a wrong one.
+ * Die Bedingung für die Menge, deren *abgeleiteter* Status am Stichtag einer
+ * der genannten ist — oder null, wenn nicht eingeschränkt werden soll.
+ *
+ * Nur die Kombinationen, die die Oberfläche anbietet, sind abgedeckt. Für
+ * alles andere kommt null zurück: lieber nicht filtern als falsch filtern.
  */
-export function applyDerivedStatusFilter<Q extends Filterable>(query: Q, statuses: EmploymentStatus[], asOf: string): Q {
+export function derivedStatusFilter(eb: Eb, statuses: EmploymentStatus[], asOf: string): Expression<SqlBool> | null {
   const wanted = new Set(statuses);
-  if (wanted.size === 0) return query;
+  if (wanted.size === 0) return null;
 
   // A single non-employed status is a straight date comparison.
-  if (wanted.size === 1 && wanted.has("Geplant")) return query.gt("entry_date", asOf) as Q;
-  if (wanted.size === 1 && wanted.has("Ausgetreten")) return query.not("exit_date", "is", null).lte("exit_date", asOf) as Q;
+  if (wanted.size === 1 && wanted.has("Geplant")) return eb("entry_date", ">", asOf);
+  if (wanted.size === 1 && wanted.has("Ausgetreten")) {
+    return eb.and([eb("exit_date", "is not", null), eb("exit_date", "<=", asOf)]);
+  }
 
   const wantsAktiv = wanted.has("Aktiv");
   const wantsKarenz = wanted.has("Karenz");
 
-  if (wantsAktiv && wantsKarenz && wanted.size === 2) {
-    // Everyone employed today, whether or not they are on leave.
-    return employed(query, asOf);
-  }
+  // Everyone employed today, whether or not they are on leave.
+  if (wantsAktiv && wantsKarenz && wanted.size === 2) return employed(eb, asOf);
 
   if (wantsKarenz && !wantsAktiv && wanted.size === 1) {
-    return employed(query, asOf)
-      .not("karenz_start_date", "is", null)
-      .lte("karenz_start_date", asOf)
-      .or(`karenz_return_date.is.null,karenz_return_date.gt.${asOf}`) as Q;
+    return eb.and([
+      employed(eb, asOf),
+      eb("karenz_start_date", "is not", null),
+      eb("karenz_start_date", "<=", asOf),
+      eb.or([eb("karenz_return_date", "is", null), eb("karenz_return_date", ">", asOf)]),
+    ]);
   }
 
   if (wantsAktiv && !wantsKarenz && wanted.size === 1) {
     // Employed but *not* inside a karenz window: either no start date, a
     // start still ahead, or a return that has already happened.
-    return employed(query, asOf).or(
-      `karenz_start_date.is.null,karenz_start_date.gt.${asOf},karenz_return_date.lte.${asOf}`
-    ) as Q;
+    return eb.and([
+      employed(eb, asOf),
+      eb.or([
+        eb("karenz_start_date", "is", null),
+        eb("karenz_start_date", ">", asOf),
+        eb("karenz_return_date", "<=", asOf),
+      ]),
+    ]);
   }
 
   // Mixed selections spanning employed and non-employed states have no UI
   // path today; filtering on a guess would be worse than not filtering.
-  return query;
+  return null;
 }