Compose ContactListScreen with mock data and child widgets

Structure ContactListScreen as a ConsumerWidget (Riverpod) that reads three providers: currentUserRoleProvider, orgFeatureFlagsProvider, and orgLabelsProvider — all of which return mock data at this stage. Keep the role-filtering and search-filtering logic in a separate pure function (List filterContacts(List all, UserRole role, String currentUserId, String query)) that is easy to unit test in isolation without widgets. Use a local StateProvider for the search query driven by ContactSearchBar's debounced onChanged callback. Use a local StateProvider for the view switcher selection.

For the ListView, pass the filtered list to ListView.builder's itemCount and itemBuilder — never use a where(...).toList() inside itemBuilder (compute the filtered list once outside the builder). When connecting to real Supabase providers in a later task, the filtering logic should migrate to the repository layer with Supabase RLS as the authoritative enforcement — add a TODO comment marking this handoff point.

Write flutter_test widget tests: (1) render with coordinator role mock data and assert all contacts are visible; (2) render with peer mentor role and assert only assigned contacts are visible; (3) enter a search query and assert the list filters to matching contacts only; (4) enter a query with no matches and assert the empty state widget is shown; (5) render with an org that has peerMentorView: false and assert ContactViewSwitcher is absent; (6) render with an org that has peerMentorView: true and assert ContactViewSwitcher is present; (7) switch ContactViewSwitcher to 'Peer Mentors' and assert PeerMentorCardWidget items are rendered instead of ContactCardWidget items; (8) tap a ContactCardWidget and assert the correct navigation event is fired (mock the router or use a navigation observer). Use pumpWidget with a ProviderScope wrapping mock providers for Riverpod-based state.