Prompt - Durcir la sécurité (RLS)

Chantier P0 (SEC-1/SEC-2). Voir ADR-0003.

Contexte : gestion-rh sur Supabase. PROBLÈME : toutes les tables ont une policy
permissive `USING (auth.role() = 'authenticated')` → tout compte connecté peut
lire/écrire toutes les données (salaires, RIB, données perso) via l'API, quel que
soit son rôle. Le cloisonnement (admin/manager/employee + scope city/entity/location)
n'existe que côté client.

Objectif : appliquer le cloisonnement EN BASE via des policies RLS, sans casser
l'app. Respecte CLAUDE.md (branche dédiée, migrations versionnées, pas de commit auto).
NE PAS appliquer de migration sur la base sans autorisation explicite : proposer
d'abord le SQL et un plan de test.

Étapes attendues :
1. Cartographie : pour chaque table (employees, monthly_payroll, leave_requests,
   transport_receipts, contract_history, weekly_schedules, planning_notes, entities,
   locations, app_users), définir qui peut SELECT/INSERT/UPDATE/DELETE selon le rôle.
2. Fonctions SQL utilitaires : is_admin(uid), employee_self(uid, emp_id),
   employee_in_scope(uid, emp_id) - en s'appuyant sur app_users(role, scope_type, scope_id).
   Attention : scope_type/scope_id doivent être versionnés (DB-1).
3. Écrire les policies RLS par table (remplacer les policies permissives).
4. Fournir un plan de test : pour un compte manager et un compte employee, vérifier
   qu'un SELECT direct sur employees/monthly_payroll ne renvoie QUE le périmètre.
5. Prévoir la compatibilité : l'app charge tout via select("*") - s'assurer que les
   écrans continuent de fonctionner (le filtrage devient à la fois DB + UI).
6. Écrire tout en migration SQL versionnée + documenter dans l'audit + ADR de remédiation.
7. Prépare le message de commit (feat(securite): ...) SANS committer.

Rappel : la ville est aujourd'hui déduite par mots-clés (fragile) - signaler si ça
complique la policy "city" et proposer une normalisation (table/colonne ville).