fix: startup resume-seek cancelled when shuffle is enabled (#2203)

applyStartupSeek() compared the armed target song against
getQueue().items[player.index], but player.index is a position in the
shuffled order while getQueue().items is always the default order. With
shuffle enabled the lookup resolves to the wrong song, the uniqueId
check fails, and the startup resume-seek is silently cancelled — the
track then plays from 0:00 and the progress poller overwrites the
persisted timestamp.

Use getCurrentSong() instead, which maps the index through
queue.shuffled, matching how the seek target is armed.

Fixes #2202

Co-authored-by: Maurits <WhoCarrot@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

src/renderer/features/player/hooks/use-queue-restore.ts

@@ -78,9 +78,7 @@ export const useInitialTimestampRestore = () => {
         }
 
         const targetUniqueId = startupSeekTargetUniqueIdRef.current;
-        const currentUniqueId = usePlayerStore.getState().getQueue().items[
-            usePlayerStore.getState().player.index
-        ]?._uniqueId;
+        const currentUniqueId = usePlayerStore.getState().getCurrentSong()?._uniqueId;
 
         if (targetUniqueId && currentUniqueId !== targetUniqueId) {
             cancelStartupSeek();