Implement search query state management in provider

Model the search query as a `StateProvider` at the module level rather than an internal field on the AsyncNotifier — this allows the search text field widget to write the query directly via `ref.read(searchQueryProvider.notifier).state = newQuery` without going through the notifier's update methods. The `ContactListRiverpodProvider` should `ref.watch(searchQueryProvider)` and derive `filteredContacts` reactively: `if (query.isEmpty) return state.contacts else return ContactSearchService.search(query, state.contacts)`. This pattern ensures filteredContacts is always a pure derivation — never independently stored — which eliminates the possibility of stale filtered state. For the remote search path (large datasets), `filteredContacts` should be an `AsyncValue` that wraps the debounced future from ContactSearchService.

Use `ref.listen(searchQueryProvider, (prev, next) { ... })` inside the notifier if you need side effects on query change, but prefer the reactive `ref.watch` derivation where possible. Reset `searchQueryProvider` to empty string in the notifier's `ref.onDispose` to prevent stale query state if the provider is later re-initialised.

Unit tests using ProviderContainer: verify filteredContacts equals full list when query is empty, verify filteredContacts is filtered subset when query is non-empty, verify clearing query returns full list without incrementing mock service call count. Widget tests: simulate typing in AppTextField, confirm ContactListView rebuilds with filtered results, confirm clearing text restores full list. Test edge case: full list refresh while query active — filtered results update to reflect new list. Use fake ContactSearchService to make local-path tests deterministic.

Test debounce cancellation via fake async timers for the remote path scenario.