feat: add tracks-read helper for shuffle

[sudoesnothing]

What

Adds src/lib/spotify/tracks.ts with one exported function:
fetchTracksForShuffle(accessToken, playlistId): Promise<string[]>.
Dispatches to GET /v1/me/tracks for the LIKED_SONGS_ID sentinel
or GET /v1/playlists/{id}/items for any other playlist, returning
a flat list of spotify:track:* URIs. Vitest coverage in
tracks.test.ts for both dispatch branches, the pagination loop,
URI filtering, and each boundary error class.

Why

Read prerequisite for the shuffle write path (#18, POST batching
into 100-URI chunks). A flat string[] gives the future add-tracks
step a clean array to chunk without the read layer coupling to the
write cap.

Uses the non-deprecated /v1/playlists/{id}/items; rationale lives
in the code comment on buildInitialUrl.

Filters to spotify:track:* only: spotify:local:* cannot be
re-added via POST, spotify:episode:* is out of v0 scope, and null
track items (catalog-removed) are dropped.

MAX_PAGES = 1000 raises SpotifyPageBudgetExceededError on exceed
rather than truncating silently, which would corrupt a shuffle. The
same throw-on-exceed pattern is worth back-porting to playlists.ts.

[ivorycrayon]

Solid. It mirrors the playlists.ts boundary pattern exactly — non-Spotify-origin refusal on the next URL, 10s per-page timeout, the shared error-class mapping, .loose() schemas with the projection as the gatekeeper — and the test coverage is thorough: both dispatch branches, the pagination loop, URI filtering, and every error class.

Two non-blocking notes:

• /v1/playlists/{id}/items is the one thing the mocked tests can't confirm — worth a real-API smoke test before the shuffle route wires this in. The tracks → items field rename already documented in playlists.ts lines up with it, so it's likely right.
• Agreed on back-porting the throw-on-exceed (SpotifyPageBudgetExceededError) to playlists.ts — its silent exit at MAX_PAGES carries the same truncation risk.