Create confidentiality_declarations Supabase table with RLS

Use a Supabase SQL migration file named with a timestamp prefix (e.g., 20260329_create_confidentiality_declarations.sql). Define the status column as a Postgres enum type (CREATE TYPE declaration_status AS ENUM ('pending','acknowledged','expired')) rather than a plain varchar with a CHECK constraint — this provides stronger type guarantees and is easier to extend. For encryption, prefer Supabase Vault (vault.create_secret / vault.decrypted_secrets) over raw pgcrypto if the Supabase project tier supports it, as Vault handles key rotation. If Vault is unavailable, use pgp_sym_encrypt/pgp_sym_decrypt with an app-level key stored in Supabase secrets.

Soft-delete enforcement: add a BEFORE DELETE trigger that raises an exception ('hard delete not permitted on confidentiality_declarations') — this is more reliable than an RLS policy alone because it also blocks service_role. The RLS policies should reference auth.uid() for the driver check and a helper function get_user_org_id() that reads from the user_profiles table for the org check.

Write SQL-level integration tests using Supabase's pgTAP or a migration test harness: (1) verify all columns exist with correct types and constraints; (2) verify RLS blocks cross-org SELECT for coordinator role; (3) verify driver can only UPDATE their own declaration status; (4) verify DELETE is blocked and returns an error; (5) verify soft-delete via deleted_at=now() succeeds; (6) verify FK to declaration_templates prevents orphaned rows; (7) verify status CHECK constraint rejects values outside the allowed enum. Also run Dart integration tests against the local Supabase emulator confirming that the DeclarationRepository (task-006) can insert, select, and soft-delete rows as expected.