fix(spotify): add pagination loop to fetch all playlist tracks

[Bi-ling-bling]

Description

Fixes a small issue where large Spotify playlists were capped at the initial API response limit (maximum 100 songs). While a comment noted that the function handled pagination, the logic to follow the next page URL was missing.

Changes

• Introduced a while loop inside fetchPlaylistTracks to continuously fetch subsequent pages via container.next until all tracks are loaded.

Testing

Tested locally with a large playlist; all tracks now load successfully without being cut off.

Functionality

Small 5-10 second delay while loading playlist.

[cupidbity]

thanks for catching this! you're right, the comment claimed pagination was handled but the loop was never there. nice find.

before i merge, a couple small things worth tightening up:

1. the catch block currently does console.error + break, which silently truncates the playlist on a mid pagination failure. that's the same shape as the bug we're trying to fix, just at a different page boundary. could you either rethrow or at least surface it to the caller? same goes for the if (!nextRes.ok) break above it, a 500 mid pagination shouldn't leave the user with half a playlist and no idea why.

2. minor style nit: PAGINATION LOOP: in caps doesn't match the rest of the comments in this file. lowercase sentence style would fit in better.

3. the blank line between fetchPlaylistTracks and the next function got deleted in the diff, can you put that back?
   on the 5 to 10 second delay you mentioned: that's almost certainly not pagination itself, it's the album art fallback further down (lines 98 to 119). every track without art fires a separate /search call, and pagination just multiplies how many of those run. i'll open a follow up issue for that and a few other perf wins (parallel page fetches via offset math, slimming the response with fields, incremental rendering), not blocking on this PR.

thanks again, this is a solid fix!