Implement ActivityTypeRepository with org scoping

Place in lib/features/activity_type/data/repositories/activity_type_repository.dart. Inject SupabaseClient via constructor (or Riverpod provider) — never instantiate Supabase.instance directly inside the repository for testability. The Supabase RLS policy on activity_types enforces org isolation server-side, but always include .eq('organization_id', orgId) in every query for defense-in-depth and explicit intent. Map the DB column is_active (boolean) to ActivityType.isActive and triggers_reimbursement_workflow to triggersReimbursementWorkflow — keep the fromJson mapping in the domain model (task-001), not in the repository.

For softDelete, use .update({'is_active': false}).eq('id', id).eq('organization_id', orgId) — the double-eq prevents cross-org soft-deletes even if RLS is misconfigured. Expose a Riverpod Provider returning ActivityTypeRepository so tests can swap in a fake implementation.

Integration tests using flutter_test with a test Supabase project (or local Supabase via Docker): (1) fetchActiveByOrg returns correct filtered list with only active types for the correct org, (2) fetchActiveByOrg for org with no active types returns empty list (not error), (3) fetchById returns null for non-existent id rather than throwing, (4) create inserts row and returned object has server-generated id and createdAt, (5) update persists changes and returns updated object, (6) softDelete sets is_active=false without removing row, (7) all methods throw RepositoryException (not PostgrestException directly) on DB error. Unit tests with mocked Supabase client covering error path: network failure wraps in RepositoryException.