The favorites feature was not working correctly when a song was initiated from outside the Library screen (e.g., from the HomeScreen). The favorite button in the player would not update its state, and the song's favorite status was not being saved.

This was caused by a potential race condition and state management issue in the `PlayerViewModel`. The favorite status was being updated manually, which could lead to inconsistencies depending on the timing of state updates from different sources.

This commit refactors the `PlayerViewModel` to handle the favorite status in a purely reactive way:

1.  **Removed `isCurrentSongFavorite` from `StablePlayerState`:** The `isCurrentSongFavorite` boolean was removed from the main player state data class to prevent the possibility of this state becoming stale.

2.  **Created a Reactive `isCurrentSongFavorite` StateFlow:** A new `StateFlow<Boolean>` was created that is derived by combining the `stablePlayerState` (to get the current song) and the `favoriteSongIds` flow from the repository. This new flow automatically emits the correct favorite status whenever the current song changes or the list of favorites is updated.

3.  **Simplified Logic:** With the new reactive flow, the manual calls to `updateFavoriteStatusForCurrentSong()` were no longer needed and have been removed. This simplifies the code and eliminates the source of the race condition.

4.  **Updated UI:** The `UnifiedPlayerSheet` (the player UI) was updated to collect its state from this new, always-correct `isCurrentSongFavorite` flow.

This change ensures a single, reactive source of truth for a song's favorite status, making the feature robust and functional across the entire application.