Implement RLS policies for audit log table

The critical risk here is using the wrong JWT claim path for org_id — verify with the rest of the codebase how org_id is embedded in the JWT (check existing RLS policies on other tables for the established pattern). Common patterns in Supabase: auth.jwt()->'app_metadata'->>'org_id', or a custom claim added via a Supabase Auth hook. Match the existing convention exactly. The INSERT WITH CHECK policy prevents a malicious client from writing audit records for another organisation — this is important because audit records affect billing and compliance for each organisation.

Do not add an UPDATE policy even as a 'deny all' policy — absence of an UPDATE policy combined with the trigger is cleaner and avoids any risk of a permissive policy accidentally overriding. Apply FORCE ROW LEVEL SECURITY in the same migration file as the policies. If the project uses Supabase Edge Functions for the orchestrator backend, ensure those functions use the user's JWT (not service_role) when inserting audit records, so RLS is exercised in the normal code path.

Write a SQL-level integration test or a Dart integration test using two separate Supabase clients authenticated with different org JWTs. Test cases: (1) User A inserts a row with org_id='org-a' — succeeds; (2) User A selects all rows — returns exactly their own row; (3) User B selects all rows — returns empty set; (4) User A attempts INSERT with org_id='org-b' (mismatched claim) — rejected by WITH CHECK policy; (5) User A attempts UPDATE — rejected by trigger; (6) service_role client attempts UPDATE — rejected by trigger. Include these as named test cases in a test file under test/database/ or equivalent. All tests must pass against local Supabase instance in CI.