Correct the policy count in the places that quote it

Six comments and doc lines put the number of RLS policies at 58. It is
21 — counted from pg_policy while building the data catalogue. The
figure appears in load-bearing prose ("all 58 policies call
is_hr_user()", "all 58 policies stay unchanged"), where being wrong by a
factor of three invites someone to go looking for the missing thirty-
seven.

The two occurrences inside supabase/migrations/ stay as they are. That
file already ran against the database; its comments record what was
believed at the time, and editing them would make the file differ from
what was applied for no gain.

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

docs/azure-migration.md

@@ -9,7 +9,7 @@ Supabase als Abhängigkeit entfernt.
 
 | | Anzahl |
 |---|---|
-| RLS-Policies | 58 |
+| RLS-Policies | 21 |
 | `auth.uid()` / `auth.users` in Migrationen | 79 |
 | Fremdschlüssel auf `auth.users` | 9 |
 | Datenzugriffe in der App (`.from()`, `.rpc()`) | 50 |
@@ -35,7 +35,7 @@ language sql security definer stable as $$
 $$;
 ```
 
-Alle 58 Policies rufen `is_hr_user()` auf. Wird hier die Herkunft der
+Alle 21 Policies rufen `is_hr_user()` auf. Wird hier die Herkunft der
 Benutzerkennung ausgetauscht, **bleiben alle Policies unverändert gültig**.
 Die Sicherheitsarchitektur wandert also *nicht* in den Anwendungscode — das
 war meine Sorge bei Variante B, und sie ist ausgeräumt.
@@ -122,7 +122,7 @@ Typen aus dem Schema, womit auch der Schema-Drift-Prüfer überflüssig wird.
 
 ## Was bewusst gleich bleibt
 
-- **Alle 58 RLS-Policies**, unverändert
+- **Alle 21 RLS-Policies**, unverändert
 - Das gesamte Schema samt Enums, Arrays, `jsonb`, PL/pgSQL, partiellen Indizes
 - `pgcrypto` und `pg_trgm` (beide auf Azure freigegeben)
 - Die Geschäftslogik in den RPCs

docs/entra-sso.md

@@ -6,7 +6,7 @@ keinen Anmeldedienst eines Anbieters mehr dazwischen.
 
 **Warum das trotzdem eine kleine Änderung ist:** die Anmeldung liefert nach wie
 vor nur eine UUID. `profiles.id` trägt weiterhin `role` und `is_active`, und
-damit bleiben `is_hr_user()` und alle 58 RLS-Policies unverändert gültig. Die
+damit bleiben `is_hr_user()` und alle 21 RLS-Policies unverändert gültig. Die
 Sicherheitsgrenze wandert nicht in den Anwendungscode.
 
 ## Einrichtung im Entra-Mandanten

lib/auth/session.ts

@@ -11,7 +11,7 @@ import { auth } from "@/auth";
 // zwischen beiden macht app_upsert_user() bei der Anmeldung, und sie
 // übernimmt für eine bereits bekannte Adresse die vorhandene profiles.id.
 // Deshalb passt die Kennung weiterhin auf das, was app_current_user_id() in
-// der Datenbank erwartet, und die 58 RLS-Policies merken vom Wechsel nichts.
+// der Datenbank erwartet, und die 21 RLS-Policies merken vom Wechsel nichts.
 
 export async function currentUserId(): Promise<string | null> {
   const session = await auth();

lib/db/index.ts

@@ -7,7 +7,7 @@ import type { Schema } from "./schema";
 //
 // ═══ Warum das keine gewöhnliche Datenbankschicht ist ═══
 //
-// Die Zugriffsrechte liegen in der Datenbank: 58 RLS-Policies rufen
+// Die Zugriffsrechte liegen in der Datenbank: 21 RLS-Policies rufen
 // is_hr_user() auf, und das fragt seit der Umstellung nicht mehr Supabase,
 // sondern `current_setting('app.user_id')` — eine Sitzungsvariable.
 //