Bug: SearchScreen has 17 collectAsStateWithLifecycle calls causing excessive recomposition

[daedaevibin]

Description

SearchScreen uses 17 collectAsStateWithLifecycle() calls at the top-level composable. Key issues:

1. stablePlayerState changes on every play/pause/skip, recomposing the whole screen even when only the now-playing indicator needs updating
2. selectedSongIds, selectedSongs, and isSelectionMode are three separate flows for one logical concern
3. favoriteSongIds (a full Set<String>) is collected at the top level
4. Album and genre selection state is held in local remember {} — lost on configuration change

Location

app/src/main/java/com/theveloper/pixelplay/presentation/screens/SearchScreen.kt (1,736 lines)

Expected Behavior

State collection should be scoped to the composables that actually use it. Related state should be merged into single flows. Album/genre selection should be ViewModel-backed.

Actual Behavior

Any state change in any of the 17 flows triggers recomposition of the entire search screen tree.

Fix

1. Move stablePlayerState collection into the now-playing indicator composable
2. Merge selectedSongIds/selectedSongs/isSelectionMode into a single MultiSelectionState flow
3. Move album/genre selection to ViewModel-backed state holders
4. Use derivedStateOf for derived state to reduce emission frequency