[Andreas-Garcia]

Summary

Once anything had been played, TrackListProvider kept a useListTracks query running: GET library/songs/?page=1&pageSize=50, with no filter. It used the result to swap in "fresh" copies of tracks that were in the playing list. Every grow curation mutation invalidated that query (referenceSongs root), and so did window refocus. On grow prod, each refetch ran a COUNT(*) over about 32M grow_song rows, hit the 30s statement timeout, and returned a 503. That is what showed up while browsing Motown.

The approach was also wrong on its own terms: page 1 of a global list almost never contains the tracks of a genre or artist list. Freshness now comes from the mutation that changed the track.

Changes

• Breaking: TrackListProvider drops the listEndpoint / listQueryKey props, the internal list query and the currentTrackList merge.
• Added: useTrackList().updateTrack(track) replaces the track with the same uuid on every loaded page, and in the selected track. When no track matches, it does nothing and returns the same list object.
• useListTracks is still exported, because hear's uploaded-library page uses it directly.
• Playground provider usage, the api/library header comment and the CHANGELOG are updated, including a migration note.

Test plan

• Replaced the list-refresh tests with a test that asserts the provider never runs a list query when a genre-playlist or artist list starts.
• Added updateTrack tests: it replaces a track on a later page and the selected track; it is a no-op (same object) for an unknown uuid; it is a no-op when there is no list.
• pnpm lint && pnpm build && pnpm test: 552 app-kit tests and 393 app-kit-ui tests pass.
• After release: in grow-front, bump to 28.0.0 and remove the two props, then confirm that selecting Motown sends no library/songs/?page=1&pageSize=50 request.

🤖 Generated with Claude Code