fix(discover): cap the taste-matched arm per album and artist before its LIMIT (#5356)

Summed tag weight rewards a track for carrying many of the user's tags, so
on the deploy two artists whose every track carries the whole lo-fi profile
took all 120 rows of the taste-unheard query. capByAlbumAndArtist ran after
the LIMIT and left 6, and the arm with the lowest skip rate (12% against
~23%) handed its slots to dormant and random.

The query now ranks within album, then within artist over what the album
cap kept, before the LIMIT: the same walk the Go cap makes, so the bucket
fills from as many artists as match. The caps come from the Go constants.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

internal/playlists/discover.go

@@ -95,8 +95,11 @@ type discoverPools struct {
 }
 
 func loadDiscoverPools(ctx context.Context, q *dbq.Queries, logger *slog.Logger, userID pgtype.UUID, dateStr string) discoverPools {
+	// The caps go into the query too (#5356): applied only here, after its
+	// LIMIT, they left a heavily tagged artist or two owning the whole bucket.
 	tasteRows, err := q.ListTasteUnheardTracksForDiscover(ctx, dbq.ListTasteUnheardTracksForDiscoverParams{
-		UserID: userID, Column2: dateStr,
+		UserID: userID, DateSeed: dateStr,
+		MaxPerAlbum: discoverMaxTracksPerAlbum, MaxPerArtist: discoverMaxTracksPerArtist,
 	})
 	if err != nil {
 		logger.Warn("discover: taste-unheard bucket failed; continuing with empty pool",