Define consent database schema and migrations

Use the Supabase CLI migration workflow: create migration file with `supabase migration new consent_schema`. Place the consent_grants and consent_audit_log table DDL in the up migration, and matching DROP TABLE statements in the down migration. The UNIQUE constraint on (mentor_id, organisation_id) in consent_grants means the application layer uses UPSERT semantics for granting consent — when a revoked mentor re-grants, set revoked_at back to NULL rather than inserting a new row. This preserves the original granted_at for audit purposes.

For the `delete_mentor_location_data` function, use `SECURITY DEFINER` so it runs with elevated privileges regardless of caller role — but add `REVOKE EXECUTE FROM PUBLIC` and `GRANT EXECUTE TO service_role, authenticated` with row-level guards inside the function body. Store the valid consent_version strings as a PostgreSQL ENUM or a reference table `consent_policy_versions` to enforce referential integrity. The ip_hash should be computed in the application layer (Dart) before sending to Supabase — never send the raw IP to the database. Consider adding a partial index `WHERE revoked_at IS NULL` on consent_grants(mentor_id, organisation_id) for the common 'is consent active?' query pattern.

Database-level tests using pgTAP via `supabase db test`. Test cases: (1) Insert a consent_grants row and verify all columns are persisted correctly; (2) Attempt to insert a second consent_grants row for the same (mentor_id, organisation_id) — assert unique constraint violation; (3) Set revoked_at to a timestamp before granted_at — assert CHECK constraint violation; (4) Verify RLS: authenticate as mentor A and attempt to SELECT mentor B's consent row — assert empty result; (5) Verify audit log is insert-only: attempt UPDATE on consent_audit_log as authenticated user — assert permission denied; (6) Call `delete_mentor_location_data()` for a mentor, then assert consent_grants row is deleted and all location rows referencing that mentor are deleted; (7) Verify ip_hash column rejects values that look like raw IP addresses (optional constraint or application-level validation). Run tests in CI with `supabase db test`.