Hay-Grade statt Verwendungsgruppe A--F

A--F stammte aus der Spezifikation, nicht vom Kunden: sechs erfundene Stufen
mit erfundenen Beschreibungen. Der Kunde bewertet nach Hay und hat die Liste
geschickt -- 13 Stufen plus einen Generic Grade.

Dieselbe Spalte fuellt im Cornerstone-Extrakt die Grade ID. Solange dort A--F
steht, ist die Datei in jeder Zeile falsch, ohne dass es beim Erzeugen
auffaellt: das Zielsystem kennt diese Kennungen nicht.

Der Typ heisst weiter paygrade_type, ist aber jetzt eine Domain ueber text mit
CHECK statt eines Aufzaehlungstyps. Ein Enum laesst sich nicht umschreiben --
Werte entfernen geht gar nicht, und add value darf im selben Vorgang, der den
neuen Wert schreibt, nicht benutzt werden. Wichtiger: die rund zehn
SQL-Funktionen, die den Wert nach paygrade_type umwandeln, bleiben unveraendert
gueltig. Jede von ihnen neu zu erzeugen hiesse, zehnmal die Gelegenheit zu
haben, aus einer veralteten Vorlage zu kopieren.

Zwei Funktionen muessen doch angefasst werden, beide per Punktaenderung an der
laufenden Definition statt per Kopie aus einer Datei: der Vorgabewert B in
hire_employee und die Beschriftung im Protokoll von promote_employee.

Der Bestand bekommt den Generic Grade. Aus A--F liesse sich kein Hay-Grade
ableiten: andere Einteilung, andere Anzahl. Geraten saehe im Extrakt genauso
aus wie erhoben.

app/api/export/employees/route.ts

@@ -97,7 +97,7 @@ function employeeExportColumns(
     { header: "Notfallkontakt Verhältnis", get: (e) => e.emergency_contact_relation ?? "" },
     { header: "Laterale Führung", get: (e) => e.is_laterale_fuehrung },
     { header: "C-Level", get: (e) => e.is_c_level },
-    { header: "Paygrade", get: (e) => e.paygrade },
+    { header: "Hay-Grade", get: (e) => e.paygrade },
     { header: "Herkunft", get: (e) => e.source },
     // The export shows the display name, not the raw enum value — a payroll
     // hand-off saying "Karenz" for what the app calls Langzeitabwesenheit