feat: track client cover size preference and prefetch on album/song responses

[brian-doherty]

Summary

• Adds a ClientCoverSizePreference DB table (with migration) that records the last cover art size requested by each user+client pair, updated on every getCoverArt call
• Extracts ensureCoverCached from ServeGetCoverArt so the resize+save logic is reusable
• Wraps the resp handler in New() with a local closure that calls prefetchCovers after any successful album/song response — no changes to individual handlers required
• prefetchCovers looks up the stored size preference for the requesting client and pre-warms the cover cache for all album/track IDs in the response (deduplicated, each in its own goroutine)
• Artist covers are excluded from prefetch since they require external Last.fm HTTP requests

Test plan

• First request for getCoverArt records size preference in DB
• Subsequent getAlbum/getAlbumList/search3 etc. responses trigger background cache warming at the stored size
• Cover is served from cache on next getCoverArt call without re-encoding
• No regression on cold-cache cover serving

🤖 Generated with Claude Code

[sentriz]

thanks Brain this is interesting, though I have a couple comments

• if we record the last cover size preference for a client, what happens when a client doesn't request a size and they have a preference set? to they get the original back?
• endpoints like getArtists without pagination will try cache for just me with a modest library size will presumably try cache ~10000 covers without a limit it looks like. might kill some devices like a raspberrypi
• the middleware check reads the response and collects ids is a little bit awkward. and creates a coupling from two places. maybe its better to have the spec.NewXFromY funcs receive a map[string]struct{} where they can add the cover ids that they "own". no coupling then, and a little less magic without the middleware