Unit test repositories and encryption utilities

Use mocktail over mockito for null-safety compatibility — mocktail requires no code generation step, keeping the test setup fast. Create a shared test/helpers/supabase_mock.dart that exports a pre-configured MockSupabaseClient to avoid duplication across the four test files. For NHF 5-chapter edge cases, create a parameterised test using a list of (chaptersCount, shouldPass) tuples and forEach() — this is more readable than six individual test cases. For crypto tests, hardcode a 32-byte test key and a known IV + ciphertext + HMAC tuple generated offline so the tests are deterministic and do not rely on random number generation.

Document the test vector source in a comment. Cover the boundary where chapter count == 5 explicitly (this is the exact NHF limit and is the most likely regression point). Integration tests hitting a real Supabase test project can be placed in test/integration/ and excluded from the standard CI run via a tag.

This task IS the testing task. The deliverable is the test suite itself. Organize tests into four test files: assignment_repository_test.dart, contact_detail_repository_test.dart, contact_form_validator_test.dart, field_encryption_utils_test.dart. Each file should have a setUp() that initialises mocks and a tearDown() that disposes them.

Use group() blocks to separate logical scenarios within each file. For the encryption tests, use known AES-GCM test vectors to validate correctness independently of the Dart crypto library's own tests. For RLS tests, mock the Supabase client to return a PostgrestException with code 42501 (insufficient_privilege) and verify the repository returns the correct typed error. Run flutter test --coverage and generate an lcov report; add a CI check that fails if coverage drops below 90% on these four files.