fix: don't crash on a Spotify page error while unshuffling (#324)

[devgianlu]

Problem

Reported in #324: the daemon crashes with

panic: invalid paged list position: -1
        tracks.(*pagedList[...]).iterHere(...)  tracks/paged-list.go:82

when a page fetch to Spotify fails (e.g. a 404 from radio-router/v3/tracks/... while paging a station/autoplay context).

Root cause

iterHere()/get() are invariant guards that assume a current position has been established (pos >= 0). A transient page-fetch failure can leave the track list stranded at pos == -1, and the next access panics. The player event loop has no panic recovery, so this takes down the whole daemon.

On current master, the specific autoplay path from the report is already mitigated (the TrySeek → moveStart fallback keeps pos >= 0), but the same class of bug is still reachable via List.ToggleShuffle:

• The unshuffle-by-refetch branch calls tl.tracks.clear() (which sets pos = -1) and then a Seek that re-pages the context to find the current track.
• If that Seek hits a page error, ToggleShuffle returns early with the list stranded at pos = -1.
• The next player event (advanceNext → GoNext/NextTracks/CurrentTrack) then panics.

clear() is the only thing that resets pos to -1 after load, and this was its only caller.

Fix

Snapshot (list, pos) before the destructive clear() and roll back on a failed re-fetch, so the list is never left at pos = -1. The rollback is atomic and total — on a transient error the list is restored to its exact prior (valid) state, and the shuffle toggle simply does not take effect.

Testing

• go build ./...
• go vet ./tracks/
• go test -tags test_unit ./tracks/ (existing unit tests pass)

Fixes #324

🤖 Generated with Claude Code