Kuendigungsschutz bekommt einen Personenkreis, die Behinderung eigene Felder

Anforderungen 5 und 5a aus dem Workshop. Migration 20260915120000.

Bisher gab es ein Kennzeichen und ein Enddatum. Das beantwortet "darf hier
ohne Weiteres beendet werden?" — nicht aber, *warum* jemand geschuetzt ist,
und davon haengt ab, wer zustimmen muss. Nachzusehen war das nur im
Papierakt, also dort, wo unter Zeitdruck niemand nachsieht.

Zwoelf Personenkreise als CHECK auf text und nicht als Aufzaehlungstyp: die
Liste ist Rechtslage und aendert sich mit dem Gesetz, ein Typ liesse einen
zurueckgenommenen Wert fuer immer stehen. Die Oberflaeche liest dieselbe
Liste aus lib/kuendigungsschutz.ts; ein Test liest die Migration und haelt
beide gegeneinander, damit die begruendete Doppelung keine stille wird.

Die begueenstigte Behinderung bekommt Kennzeichen, Grad, Beginn und Ende —
vier Spalten und nicht eine zusammengesetzte, weil in Excel danach
gefiltert und summiert wird. Datenbankseitig sind sie *nicht* an den
Personenkreis gekettet: eine solche Bedingung scheiterte genau dann, wenn
jemand den Kreis korrigiert und der Grad noch dransteht. Die Oberflaeche
stellt den Zusammenhang her.

Dazu zwei Dinge, die auf dem Weg auffielen:

  * Der Nachtlauf wendete bei einer auf spaeter datierten Aenderung nur
    Person und Vertrag an — die ganze Gruppe "role" fiel weg. Betriebsrat,
    Dienstwagen, Kollektivvertrag, Arbeitstage, Teilzeit und
    Kuendigungsschutz wurden erfasst, in der Historie vermerkt, protokolliert
    und am Stichtag nicht geschrieben. Sichtbar wurde das nie. Die neuen
    Felder haetten den Fehler geerbt; er ist jetzt fuer alle behoben.
  * Der Mitarbeiter-Export filterte ohne Stichtag ueber die Spalte `status`,
    mit Stichtag ueber die Ableitung. Der Export nach "Ausgetreten" liess
    damit genau die Leute aus, die gerade ausgetreten sind.

app/api/export/employees/route.ts

@@ -5,6 +5,7 @@ import { fmtName, todayIso } from "@/lib/format";
 import { subtreeOf } from "@/lib/org";
 import { loadPlacements, loadReportingLineMap } from "@/lib/placement";
 import { LEERE_CRITERIA, parseCriteria, passtImSpeicher } from "@/lib/report-criteria";
+import { derivedStatusFilter } from "@/lib/employee-status-filter";
 import { deriveStatusAsOf, parseIsoDateParam, parseStatuses, type OrgLookups } from "@/lib/reports";
 import { applyCriteria, loadDependentsCounts, loadOrgLookups, type ReportFilters } from "@/lib/reports-data";
 import { requireHrUser } from "@/lib/auth/require-hr";
@@ -49,7 +50,15 @@ export async function GET(request: NextRequest) {
       function employeeQuery() {
         let q = tx.selectFrom("employees").selectAll().orderBy("last_name").orderBy("id");
         if (filters.location) q = q.where("location_id", "=", filters.location);
-        if (!asOf) q = q.where("status", "in", statuses);
+        // Ohne Stichtag wurde hier bisher über die Spalte `status` gefiltert,
+        // mit Stichtag weiter unten über die Ableitung. Das sind zwei
+        // verschiedene Antworten auf dieselbe Frage: die Spalte hängt nach,
+        // sobald ein Austritt mit einem damals künftigen Datum erfasst wurde
+        // (Migration 20260814100000 zieht sie nicht nach). Der Export nach
+        // „Ausgetreten" liess damit genau die Leute aus, die gerade
+        // ausgetreten sind. Jetzt beidemale dieselbe Regel, nur einmal in SQL
+        // und einmal im Speicher.
+        if (!asOf) q = q.where((eb) => derivedStatusFilter(eb, statuses, stichtag) ?? eb.val(true));
         // Dieselben Bedingungen wie im Bericht daneben — sonst stimmt die
         // Zahl auf dem Bildschirm nicht mit der Zeilenzahl im Export überein.
         return applyCriteria(q, filters.criteria ?? LEERE_CRITERIA);
@@ -150,7 +159,17 @@ function employeeExportColumns(
     { header: "Dienstwagen", get: (e) => e.has_dienstwagen },
     { header: "Antriebsart", get: (e) => e.dienstwagen_art ?? "" },
     { header: "Besonderer Kündigungsschutz", get: (e) => e.has_kuendigungsschutz },
+    { header: "Personenkreis", get: (e) => e.kuendigungsschutz_grund ?? "" },
+    { header: "Kündigungsschutz ab", get: (e) => e.kuendigungsschutz_ab, kind: "date" },
     { header: "Kündigungsschutz bis", get: (e) => e.kuendigungsschutz_bis, kind: "date" },
+    // Der Bericht, den der Workshop verlangt hat (Anforderung 5a): wer ist
+    // begünstigt behindert, mit wieviel Prozent, ab und bis wann. Vier
+    // Spalten statt einer zusammengesetzten — in Excel wird danach gefiltert
+    // und summiert, und ein Text wie „50% seit 2019" liesse beides nicht zu.
+    { header: "Begünstigt behindert", get: (e) => e.ist_beguenstigt_behindert },
+    { header: "Grad der Behinderung (%)", get: (e) => e.behinderung_grad ?? "" },
+    { header: "Bescheid ab", get: (e) => e.behinderung_ab, kind: "date" },
+    { header: "Bescheid bis", get: (e) => e.behinderung_bis, kind: "date" },
     { header: "Teilzeitvariante", get: (e) => e.teilzeit_art ?? "" },
     { header: "Teilzeit bis", get: (e) => e.teilzeit_bis, kind: "date" },
     { header: "Notfallkontakt", get: (e) => e.emergency_contact_name ?? "" },