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>
Maurits