Implement Assignment Repository

Follow the same structural pattern as `ContactDetailRepository` (task-010's output) for consistency — same file location convention, same exception handling pattern, same model mapping approach. The `Assignment` model should be an immutable Dart class using `copyWith` — consider using `freezed` only if it is already a project dependency; otherwise a plain class is sufficient. The Supabase table name is likely `assignments` — verify against the database schema before writing queries. Use `supabase.from('assignments').select('id,contact_id,org_id,...').eq('org_id', orgId).eq('contact_id', contactId).eq('status', 'active')` pattern.

Map `snake_case` JSON keys to `camelCase` Dart fields in a `fromJson` factory. The repository should be injected via the `assignmentRepositoryProvider(orgId)` family provider defined in task-017 — ensure the constructor signature accepts a `SupabaseClient` as a dependency (not constructed internally) to support provider injection and test overrides.

Write unit tests in `test/data/repositories/assignment_repository_test.dart` using a `FakeSupabaseClient` (implement the Supabase client interface with in-memory data). Test scenarios: (1) getActiveAssignments returns correctly mapped Assignment list for a known contactId; (2) getActiveAssignments returns empty list when no records match; (3) getAssignmentHistory returns records sorted by date descending; (4) getAssignmentById returns null for a non-existent ID; (5) Supabase network error is converted to AssignmentRepositoryException (not rethrown raw); (6) orgId mismatch yields empty result (simulating RLS). Use `flutter_test`. Aim for 100% branch coverage of the repository class.