Create credential vault reference column migration

This migration must run after both task-003 (RLS policies exist) and task-004 (Vault functions exist). In the migration SQL, add the column with ALTER TABLE organization_integrations ADD COLUMN IF NOT EXISTS vault_secret_id UUID. The CHECK constraint for active integrations should use: ALTER TABLE organization_integrations ADD CONSTRAINT chk_active_integration_has_vault_ref CHECK (status::text != 'active' OR vault_secret_id IS NOT NULL). Regarding cross-schema FK to vault.secrets: Supabase Vault does not officially support foreign key constraints into vault.secrets because it is a protected schema.

Document this limitation explicitly and enforce referential integrity at the application layer in the OrganizationIntegrationRepository Dart class — before inserting a vault_secret_id, verify the secret exists via a retrieve_credential() probe call. In the Dart repository, always fetch organization_integrations rows with explicit column projection (never SELECT *) to ensure vault_secret_id is never accidentally returned to the client.

Migration validation tests in Supabase local environment. Test cases: (1) Migration applies cleanly on top of task-002 and task-003 migrations. (2) INSERT of an 'active' status row without vault_secret_id is rejected by the CHECK constraint. (3) INSERT of an 'inactive' status row without vault_secret_id succeeds.

(4) UPDATE of a row changing status to 'active' without setting vault_secret_id is rejected. (5) Rollback migration removes the column and constraint without error. (6) Coordinator-role RLS policy cannot retrieve vault_secret_id (query returns NULL or column is absent from result set). (7) Admin-role RLS policy can retrieve vault_secret_id for their own organization's rows.

Run all tests as part of the full migration suite (supabase db reset).