Show the Offboarding tab from the day the exit is recorded, not the day it takes effect

The tab was keyed off employee.status === "Ausgetreten", and that stays
wrong for weeks: terminate_employee writes exit_date immediately no
matter how far out the date is, but only flips status once the date
itself arrives. A termination entered today for four weeks out left the
tab invisible for the entire notice period — exactly the stretch in
which IT access, hardware and deregistration actually get worked
through, and exactly where the checklist was supposed to live "next to
Onboarding," per the report that caught this.

The rule now reads exit_date instead: not null, and not a No Show
(which sets exit_date too, to the entry day, but never worked a day and
gets no checklist). rehire_employee resets both exit_date and
exit_reason to null, so a rehired person's tab still disappears the
same way it did before — nothing about that case changed, only the
signal the check reads.

Verified against the real database with the exact shape from the
report: a termination dated 30 days out. Status stays "Aktiv", the
checklist exists immediately, and the tab's own predicate says yes.

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

lib/offboarding.ts

@@ -66,15 +66,25 @@ export function fortschritt(staende: AufgabenStand[]): Fortschritt {
 /**
  * Ob eine Person offzuboarden ist — die Regel hinter dem Reiter.
  *
- * Nur ein echter Austritt zählt. No Show scheidet zwar mit demselben Status
- * „Ausgetreten" aus, hat aber nie einen Tag gearbeitet: keinen IT-Zugang, der
- * eingerichtet wurde, keine GKK-Anmeldung, kein Dienstzettel. Ein Reiter mit
- * einer leeren Liste wäre dort ein Etikett ohne Inhalt.
+ * Geprüft wird `exit_date`, nicht `status`. Eine künftige Beendigung setzt
+ * beide Felder sofort — terminate_employee schreibt `exit_date` unabhängig
+ * davon, ob der Stichtag schon erreicht ist —, während `status` erst am
+ * Stichtag selbst auf „Ausgetreten" wechselt. Bis dahin steht die Person
+ * weiterhin als „Aktiv"; die vier Wochen bis zum Austritt sind aber genau die
+ * Zeit, in der IT-Zugänge, Hardware und Anmeldungen abgewickelt werden. Mit
+ * `status` als Bedingung bliebe der Reiter bis zum letzten Arbeitstag
+ * unsichtbar — zu spät, um dort etwas vorzubereiten.
  *
- * Wird die Person wiedereingestellt, wechselt der Status weg von
- * „Ausgetreten", und die Regel verneint wieder — die Checkliste bleibt in den
- * Daten stehen, nur ihr Reiter verschwindet, solange sie ohne Gegenstand ist.
+ * No Show hat `exit_date` ebenfalls gesetzt (den Eintrittstag), aber nie
+ * einen Tag gearbeitet: keinen IT-Zugang, der eingerichtet wurde, keine
+ * GKK-Anmeldung, kein Dienstzettel. Ein Reiter mit einer leeren Liste wäre
+ * dort ein Etikett ohne Inhalt — deshalb der Ausschluss über `exit_reason`.
+ *
+ * Wird die Person wiedereingestellt, setzt rehire_employee `exit_date` und
+ * `exit_reason` ausdrücklich auf null zurück, und die Regel verneint wieder —
+ * die Checkliste bleibt in den Daten stehen, nur ihr Reiter verschwindet,
+ * solange sie ohne Gegenstand ist.
  */
-export function gehoertOffboarding(employee: { status: string; exit_reason: string | null }): boolean {
-  return employee.status === "Ausgetreten" && employee.exit_reason !== "No Show";
+export function gehoertOffboarding(employee: { exit_date: string | null; exit_reason: string | null }): boolean {
+  return employee.exit_date !== null && employee.exit_reason !== "No Show";
 }