Add many-to-many matter participant authorization model

From the PR description

Motivation

• Enforce portal access using an explicit many-to-many matter_participants table so matter access is granted only to participants with the appropriate role rather than relying on implicit ownership or frontend hiding.
• Apply consistent server-side and database-level (Supabase RLS) authorization across matter-scoped resources (matters, documents, portal messages, tasks, intake submissions, downloadable files) so clients/attorneys/reviewers/paralegals can only access matters they are assigned to while partners/admins have full access.

Description

• Added migration backend/migrations/001_matter_participants_access.sql to create matter_participants (many-to-many matter <> user) with participant_role constraint and index.
• Implemented SQL helpers current_portal_role() and can_access_matter(p_matter_id uuid) that check JWT role and membership in matter_participants, granting global access to partner/admin and role-specific checks for client, attorney, reviewer, and paralegal.
• The migration dynamically enables RLS and creates select and all (read/write) policies on matters, documents, portal_messages, tasks, intake_submissions, and downloadable_files (only if those tables exist) using public.can_access_matter(matter_id) for both using and with check clauses.
• Added backend authorization helpers in backend/src/lib/access.ts: canAccessMatterByRole(...) to evaluate participant membership from the server and ensureMatterScopedResourceAccess(...) to resolve a resource's matter_id and validate access for reuse by route handlers.

Testing

• No automated test suite was executed against these changes in this rollout; only the migration and code files were added and committed.

Codex Task