Die Cornerstone-ID als eigenes, freiwilliges Feld

Cornerstone fuehrt jede Person unter einer eigenen Kennung. Der Export
dorthin trug in "User ID" und "Username" bisher die Alpenwerk-UUID --
richtig, solange es nichts Besseres gab, aber nicht die Kennung, unter
der Cornerstone die Person kennt. Jetzt steht dort diese Spalte.

Freiwillig, weil die Zuordnungstabelle des Kunden fuer 434 der 784
Personen keine Kennung liefert. Eindeutig, weil eine Kennung genau einer
Person gehoert. Als Text, weil fuehrende Nullen in einer numerischen
Spalte verlorengingen.

Ohne hinterlegte Kennung bleiben User ID und Username **leer**. Ein
Rueckfall auf die UUID braechte zwei Kennungsarten in eine Datei, ohne
dass es auffiele, und legte in Cornerstone eine zweite Person neben der
bestehenden an. Eine fehlende Angabe soll fehlen; dafuer gibt es einen
eigenen Test.

Fuenf Funktionen mussten mit -- dieselbe Liste und derselbe Grund wie bei
der Firmen-E-Mail: hire_employee und rehire_employee teilen sich den
Schritt "Person", change_employee_data macht das Feld aenderbar,
apply_due_pending_changes sorgt dafuer, dass eine datierte Aenderung
nicht verfaellt, app_feld_karte haelt den Eintrag in der Historie
richtigstellbar. Die Migration ist wieder erzeugt, nicht abgeschrieben,
und prueft jede der fuenf einzeln.

Erfasst wird das Feld in der Akte, in "Daten aendern", bei Einstellung
und Wiedereintritt sowie ueber den Massenimport; es steht im
Mitarbeiterexport und fuellt im Cornerstone-Export User ID und Username.

lib/cornerstone.ts

@@ -160,6 +160,7 @@ export type CornerstoneQuelle = {
   title_suffix: string[];
   gender: string;
   company_email: string | null;
+  cornerstone_id: string | null;
   address: string | null;
   postal_code: string | null;
   city: string | null;
@@ -187,19 +188,24 @@ export type CornerstoneKontext = {
 export function baueCornerstoneZeile(p: CornerstoneQuelle, k: CornerstoneKontext): CornerstoneZeile {
   // Zwei Kennungen, zwei Herkünfte:
   //
-  //   User ID + Username  die UUID aus Alpenwerk (employees.id)
+  //   User ID + Username  die Cornerstone-ID (employees.cornerstone_id)
   //   Local System ID     die Personalnummer, wie LOGA sie vergibt
   //
-  // Benutzername und Benutzer-ID sind in Alpenwerk stets derselbe Wert —
-  // liefen sie auseinander, zeigte Cornerstone zwei Kennungen für eine
-  // Person, und jeder Verweis darauf träfe womöglich die falsche.
+  // Benutzername und Benutzer-ID sind stets derselbe Wert — liefen sie
+  // auseinander, zeigte Cornerstone zwei Kennungen für eine Person, und
+  // jeder Verweis darauf träfe womöglich die falsche.
   //
-  // Die UUID und nicht die Personalnummer, weil sie die Kennung ist, die
-  // sich nie ändert: eine Personalnummer kann berichtigt werden, und dann
-  // wäre die Person in Cornerstone eine andere.
+  // Hier stand die Alpenwerk-UUID, solange es nichts Besseres gab. Seit
+  // 20260928100000 führt Alpenwerk die Kennung mit, unter der Cornerstone
+  // die Person selbst kennt; die UUID sagte dort niemandem etwas.
+  //
+  // **Leer, wenn keine hinterlegt ist.** Ein Rückfall auf die UUID brächte
+  // zwei Kennungsarten in eine Datei, ohne dass es jemandem auffiele — und
+  // legte in Cornerstone eine zweite Person neben der bestehenden an. Eine
+  // fehlende Kennung ist eine fehlende Angabe und soll als solche auffallen.
   //
   // Der Anmeldename des Verzeichnisdienstes steht nur im Customfield AD.
-  const kennung = p.id;
+  const kennung = p.cornerstone_id ?? "";
   const nummer = String(p.personnel_number);
   const adName = benutzername(p.first_name, p.last_name);
   const kst = p.position_id ? k.kostenstelle.get(p.position_id) : undefined;