Write down what is actually in the database

The one document describing the schema, docs/data-model.md, predates two
rebuilds. It names divisions/departments/teams and a positions table that
no longer exist, describes Supabase auth with an anon key and a service
role that were removed, and puts the policy count at 58 when it is 21.
Anyone reading it to understand the data would have been misled on every
count.

docs/datenkatalog.md replaces it, and was not typed up from memory: the
columns, defaults, keys and check constraints were read out of
information_schema and pg_catalog on the running database. Fifteen
tables, 142 columns, ten enum types, 21 policies. Where a rule appears in
prose, the constraint it comes from is named next to it.

Some of it only became visible by asking the database rather than the
migrations. generate_company_email and the is_hr_admin pair are still
defined but nothing calls them any more. Position numbers look like a
six followed by seven digits because the generator builds them that way,
not because anything enforces it — the column requires only uniqueness.
monthly_salary_gross is dead weight kept in case old rows hold data.

Three claims I drafted were wrong and the database said so: the position
number format, the event trigger's name (ensure_rls, the function behind
it is rls_auto_enable), and which tables deviate from the plain
is_hr_user() policy.

The old document keeps a pointer at the top instead of being deleted —
it is linked from the security review, and a stale document that says so
is more useful than a dead link.

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

docs/data-model.md

@@ -1,5 +1,23 @@
 # Datenmodell
 
+> **Veraltet — siehe `docs/datenkatalog.md`.**
+>
+> Dieses Dokument beschreibt den Stand vor zwei Umbauten und stimmt in
+> wesentlichen Teilen nicht mehr:
+>
+> - Die Org-Tabellen `divisions` / `departments` / `teams` und die Tabelle
+>   `positions` gibt es nicht mehr. An ihrer Stelle steht das SAP-OM-Modell
+>   (`org_units`, `jobs`, `om_positions`, `position_assignments`) mit
+>   zeitabhängigen Zuordnungen.
+> - Supabase Auth, der anon key und die Service-Role sind weg. Angemeldet
+>   wird über Auth.js gegen Entra ID, die Konten stehen in `app_users`, und
+>   der Zugriff läuft über eine Rolle ohne `BYPASSRLS`.
+> - Die Zahl der RLS-Policies ist 21, nicht 58.
+>
+> Der Datenkatalog wurde aus der laufenden Datenbank erzeugt und gilt. Was
+> hier noch stimmt — die Grundprinzipien und der Abschnitt zu den
+> effective-dated changes — steht dort ebenfalls.
+
 Beschreibt das tatsächliche Supabase-Schema (siehe `supabase/migrations/`),
 nicht ein generisches HR-Schema. Quelle der Wahrheit sind immer die
 Migrationen; dieses Dokument ist eine lesbare Zusammenfassung und wird bei