This change fixes a critical bug where the playback queue did not update in real-time when reordered by the user. The previous implementation using 'moveMediaItem' was insufficient.

The new implementation in the 'reorderQueueItem' function in 'PlayerViewModel.kt' completely rebuilds the media queue. It saves the state of the current song, reorders the song list, and then resets the player's queue with the new order, resuming playback seamlessly from the saved position. This ensures the player's state is always synchronized with the UI and respects user changes instantly.

This change fixes a critical bug where the playback queue did not update in real-time when reordered by the user. The issue was caused by a lack of proper listeners for timeline changes in both the PlayerViewModel and the MusicService.

This commit:
- Uncommented the call to update the playback queue in `PlayerViewModel.kt`'s `onTimelineChanged` listener, ensuring the UI is always in sync with the player's state.
- Implemented the `onTimelineChanged` callback in `MusicService.kt` to update the notification and any widgets, ensuring all components reflect the correct queue order.

This two-part solution ensures that reordering the queue is now seamlessly and instantly reflected across the entire application without causing audio interruptions.

The TransitionController, which handles pre-buffering the next track, was not listening for timeline changes. This caused the player to play the old "next" song after the queue was reordered, as it had already been pre-buffered.

This change adds an `onTimelineChanged` listener to the `TransitionController`. When the timeline changes due to a playlist modification, the controller now reschedules the next track for preparation. This ensures the correct song is always pre-buffered, fixing the reordering bug without causing audio interruptions.

The TransitionController, which handles pre-buffering the next track, was not listening for timeline changes. This caused the player to play the old "next" song after the queue was reordered, as it had already been pre-buffered.

This change adds an `onTimelineChanged` listener to the `TransitionController`. When the timeline changes due to a playlist modification, the controller now reschedules the next track for preparation. This ensures the correct song is always pre-buffered, fixing the reordering bug without causing audio interruptions.

The playback queue was not updating in real-time because the UI and the player engine's pre-buffering logic were not synchronized with the player's internal timeline after a change.

This commit fixes this by making both the `PlayerViewModel` and the `TransitionController` react to `onTimelineChanged` events with the reason `TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED`.

- `PlayerViewModel` now updates the UI queue state based on the new timeline, ensuring the user sees the correct order.
- `TransitionController` now reschedules the next track preparation, ensuring the correct song is pre-buffered and played next.

This establishes the player's timeline as the single source of truth and resolves the queue desynchronization bug without audio stuttering or other regressions.

The playback queue was not updating in real-time because the UI and the player engine's pre-buffering logic were not synchronized with the player's internal timeline after a change.

This commit fixes this by making both the `PlayerViewModel` and the `TransitionController` react to `onTimelineChanged` events with the reason `TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED`.

- `PlayerViewModel` now updates the UI queue state based on the new timeline, ensuring the user sees the correct order.
- `TransitionController` now reschedules the next track preparation, ensuring the correct song is pre-buffered and played next.

This establishes the player's timeline as the single source of truth and resolves the queue desynchronization bug without audio stuttering or other regressions.

This commit fixes a bug that prevented real-time reordering of the playback queue. The previous implementation of the `DualPlayerEngine` managed its own copy of the playlist, which would become stale when the user reordered the queue, leading to incorrect playback.

The solution was to refactor the handover logic in `DualPlayerEngine` to no longer manage the playlist. Instead, it now relies on the `MediaController`'s timeline as the single source of truth. The engine now simply commands the master player to seek to the next item in the timeline, which correctly reflects the user's reordering.

Additionally, the `prepareNext` function was made more robust by ensuring the auxiliary player is always cleared before preparing a new track, and a `cancelNext` function was added to handle cases where the queue is reordered and the current song becomes the last.

This commit fixes a bug that prevented real-time reordering of the playback queue. The solution addresses two key issues:

1.  **UI State Persistence:** The `PlayerViewModel` now immediately updates the UI state when the queue is reordered. This provides an optimistic update that prevents the visual list from reverting to its old order, ensuring a smooth user experience.

2.  **Playback Engine Logic:** The `DualPlayerEngine`'s handover logic was refactoredd to no longer manage its own copy of the playlist. Instead, it now relies on the `MediaController`'s timeline as the single source of truth. The engine simply commands the master player to seek to the next item in the timeline, which correctly reflects the user's reordering. The `prepareNext` function was also made more robust.

This commit fixes a persistent bug that prevented real-time reordering of the playback queue. The root cause was a race condition in `PlayerViewModel`, where an optimistic UI update would be overwritten by a listener syncing with a stale `MediaController` state.

The solution addresses three key areas:

1.  **Race Condition Elimination:** The `onTimelineChanged` listener in `PlayerViewModel` has been modified to no longer update the UI queue. This prevents the stale player state from overwriting the user's intended order.

2.  **UI State Persistence:** The `reorderQueueItem` function now immediately and authoritatively updates the local UI state, making the user's action the single source of truth for the visual queue order.

3.  **Playback Engine Robustness:** The `DualPlayerEngine`'s handover logic was refactored to rely on the `MediaController`'s timeline instead of its own copy of the playlist. This ensures that playback transitions correctly follow the reordered queue.

When the playback queue is reordered, the TransitionController was
previously rescheduling the next track transition immediately. This
interfered with the user's intended order because it was based on a
state that could be stale right after the reordering action.

This change modifies the onTimelineChanged listener in the
TransitionController. Now, when a TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED
event occurs, it cancels any pending transition scheduler job and
any prepared next track in the player engine.

This ensures that the player respects the newly updated queue order
without interference. The correct transition for the new next track will be
scheduled naturally when the current item finishes and onMediaItemTransition
is triggered.

This commit addresses a set of related bugs that caused an inconsistent user experience when managing the playback queue.

The primary issue was that reordering songs in the queue did not persist in the actual playback order. This was caused by the `TransitionController` interfering with the `MediaController`'s timeline by scheduling a transition based on the old queue state immediately after a reorder operation. This is now fixed by canceling any pending transitions in `onTimelineChanged` when the playlist is modified.

Additionally, two related UI bugs were fixed:
1.  When a song was deleted from the queue, the UI would not update until the next player event. The `removeSongFromQueue` function in `PlayerViewModel` now performs an optimistic update on the UI state for an immediate visual change.
2.  The drag-and-drop reordering logic in `QueueBottomSheet.kt` was using a temporary, mutated list to calculate the destination index, causing the reorder command to fail. This is corrected by using the original, stable queue list for the calculation.

These changes ensure that queue management is now robust, with UI actions immediately and correctly reflected in both the application's state and the playback engine.