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.

lib/hay-grade.ts

@@ -0,0 +1,55 @@
+import type { PaygradeType } from "./types";
+
+// Die Hay-Grades — die Bewertungsstufen, die der Kunde tatsächlich führt.
+//
+// Bis September 2026 stand an dieser Stelle eine Verwendungsgruppe A–F samt
+// Beschreibungen („B – Qualifiziert"). Die stammte aus der Spezifikation, nicht
+// vom Kunden: sechs erfundene Stufen. Dieselbe Spalte füllt im
+// Cornerstone-Extrakt die „Grade ID", und dort ist A–F keine Kennung, die das
+// Zielsystem kennt — die Datei wäre in jeder Zeile falsch gewesen, ohne dass
+// es beim Erzeugen aufgefallen wäre.
+//
+// Gespeichert wird die ID, angezeigt der Titel. Bei den HG-Stufen ist beides
+// dasselbe; nur „Generic Grade" trägt als ID einen Bindestrich. Der steht so
+// in der Tabelle des Kunden und wird hier nicht in eine leere Angabe
+// übersetzt: ein Bindestrich ist dort ein Wert, kein fehlender.
+//
+// Dieselbe Liste steht in Migration 20260928140000 als CHECK der Domain
+// paygrade_type; tests/unit/hay-grade.test.ts hält beide gegeneinander.
+export const HAY_GRADES: readonly { value: PaygradeType; label: string }[] = [
+  { value: "-", label: "Generic Grade" },
+  { value: "HG09", label: "HG09" },
+  { value: "HG10", label: "HG10" },
+  { value: "HG11", label: "HG11" },
+  { value: "HG12", label: "HG12" },
+  { value: "HG13", label: "HG13" },
+  { value: "HG14", label: "HG14" },
+  { value: "HG15", label: "HG15" },
+  { value: "HG16", label: "HG16" },
+  { value: "HG17", label: "HG17" },
+  { value: "HG18", label: "HG18" },
+  { value: "HG19", label: "HG19" },
+  { value: "HG19P", label: "HG19P" },
+  { value: "HG20", label: "HG20" },
+] as const;
+
+export const HAY_GRADE_WERTE: readonly PaygradeType[] = HAY_GRADES.map((g) => g.value);
+
+/**
+ * Die Vorgabe — und zugleich der Wert, den der Bestand bei der Umstellung
+ * bekommen hat.
+ *
+ * Aus A–F liesse sich kein Hay-Grade ableiten: die alten Stufen waren eine
+ * andere Einteilung mit einer anderen Anzahl. Jede Zuordnung wäre geraten,
+ * und geraten sähe im Extrakt genauso aus wie erhoben.
+ */
+export const HAY_GRADE_STANDARD: PaygradeType = "-";
+
+/** Der anzuzeigende Titel; unbekannte Werte bleiben, wie sie in der Zeile stehen. */
+export function hayGradeLabel(wert: string | null | undefined): string {
+  return HAY_GRADES.find((g) => g.value === wert)?.label ?? wert ?? "–";
+}
+
+export function istHayGrade(wert: string | null | undefined): wert is PaygradeType {
+  return HAY_GRADE_WERTE.includes(wert as PaygradeType);
+}