Integration test: end-to-end search flow

Structure the test file with a single main() entry point and group tests by flow scenario: group('Online search flow', ...), group('Offline fallback flow', ...), group('Voice input flow', ...), group('Empty state flow', ...). Use ProviderScope overrides (Riverpod) or BlocProvider with mock blocs to inject test doubles. For debounce handling, prefer tester.pump(Duration(milliseconds: debounceMs + 50)) over pumpAndSettle() to have predictable timing. Keep mock data minimal (3–5 contact records) to keep test intent clear.

Assert both data (result count, content) and UI (widget visibility, text content) to ensure the full pipeline works. Avoid testing implementation details of individual widgets here — that is covered by widget tests in task-009.

Use the integration_test package with testWidgets() in a dedicated integration_test/ directory. Inject mock implementations of IContactSearchRepository (returns predefined ContactSearchResult lists) and IOfflineSearchRepository via dependency injection or provider overrides. Use FakeAsync or tester.pump(Duration(milliseconds: 350)) to advance past the debounce timer without real delays. For offline tests, configure the mock Supabase repository to throw a SocketException, then assert the offline banner appears and results are sourced from the offline mock.

Use a MockSpeechRecognitionService that immediately returns a predefined transcription string. Assert semantics announcements using tester.getSemantics() after pumpAndSettle(). Each scenario should be an independent test with no shared mutable state between tests.