feat(discover): rank suggestions by taste-tag overlap — #2377 (server)

The payoff slice. Until now a candidate's only claim on a slot was "some
artist you play is adjacent to it in a similarity graph" — a fact that says
nothing about whether the music sounds like anything you like. Now the
candidate's own folksonomy tags (cached by slice 5) are compared against
the user's taste-profile tags, so the deck ranks on taste and can say WHY.

The blend is MULTIPLICATIVE — score × (1 + weight × overlap) — and that
choice carries the whole safety argument:

  - An untagged candidate has overlap 0, so its score is EXACTLY unchanged.
    Tag coverage is permanently partial (#2376); it must cost a candidate
    nothing, not sink it (rule #131).
  - Nothing can leapfrog on tags alone. An additive term with a large
    weight would let a near-zero-similarity artist outrank a strong match
    for sharing one popular tag, which reads as noise.
  - Weight 0 restores pure similarity order bit-for-bit, so the operator's
    knob has a real off position.

overlap = Σ(shared) candWeight × normalizedTasteWeight ÷ Σ(all) candWeight.
Normalizing the taste side by the user's strongest tag makes the score
comparable across users (taste weights accumulate with listening, so a
heavy listener's raw numbers dwarf a new user's while meaning the same
thing). Dividing by the candidate's own mass makes it comparable across
candidates, so a densely-tagged artist can't win on tag count alone.

Applied to the whole over-fetched pool BEFORE selectSuggestions, so the
rotation and diversity rules operate on blended scores — boosting only the
twelve already chosen by similarity would leave the re-ranking undone.

A query failure is returned, NOT degraded past. Graceful degradation is
for expected absence (no taste profile, no cached tags) and both are
handled explicitly as empty inputs; swallowing a real error would hide a
broken DB behind a subtly worse ranking that nothing reports.

Migration 0051 adds a FOURTH tuning scope rather than columns on
taste_tuning, because snooze_days lives here too and a snooze must never
be read as taste signal (#2374) — filing it under 'taste' would put it one
careless join from the leak that design forbids. Expanding
recommendation_tuning_audit's CHECK is in the same migration per rule #36,
and a test asserts the audit row lands, which is what would catch its
absence.

snooze_days moves out of a Go constant onto the tuning card (rule #25),
closing the deferral from #2374.

Tag-overlap tests use deliberately SKEWED fixtures: an evenly-matching pool
cannot exercise a re-ranking, since every candidate gets the same
multiplier and the order is unchanged whether the blend works or not.

Admin UI + client attribution follow in this batch — rule #27.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

internal/api/suggestions.go

@@ -25,6 +25,12 @@ type suggestionView struct {
 	Name        string                 `json:"name"`
 	Score       float64                `json:"score"`
 	Attribution []seedContributionView `json:"attribution"`
+	// MatchedTags are the candidate's tags that overlap the user's taste
+	// profile, strongest first (#2377) — the "matches: shoegaze, melancholic"
+	// line. Omitted when empty, which is common: tag coverage for
+	// out-of-library artists is permanently partial (#2376), and the card
+	// falls back to the seed attribution it has always shown.
+	MatchedTags []string `json:"matched_tags,omitempty"`
 	// ImageURL is resolved on-demand from Lidarr (out-of-library
 	// artists have no local art row). Omitted when Lidarr is disabled
 	// or has no match — the client falls back to a placeholder. Not
@@ -71,7 +77,11 @@ func (h *handlers) handleListSuggestions(w http.ResponseWriter, r *http.Request)
 		halfLife = f
 	}
 
-	suggestions, err := recommendation.SuggestArtists(r.Context(), h.pool, user.ID, halfLife, limit)
+	// Read the tuned weight per request so an admin change takes effect on the
+	// next refresh, no restart (rule #25).
+	tagWeight := h.recSettings.Discover().TagOverlapWeight
+	suggestions, err := recommendation.SuggestArtists(
+		r.Context(), h.pool, user.ID, halfLife, limit, tagWeight)
 	if err != nil {
 		h.logger.Error("api: list suggestions", "err", err)
 		writeErr(w, apierror.InternalMsg("failed to load suggestions", err))
@@ -92,19 +102,17 @@ func (h *handlers) handleListSuggestions(w http.ResponseWriter, r *http.Request)
 		}
 		out = append(out, suggestionView{
 			MBID: s.MBID, Name: s.Name, Score: s.Score, Attribution: attr,
+			MatchedTags: s.MatchedTags,
 		})
 	}
 	h.resolveSuggestionArt(r.Context(), out)
 	writeJSON(w, http.StatusOK, out)
 }
 
-// Snooze duration bounds. 90 days is long enough that a parked suggestion
-// stops feeling like it's nagging, short enough that a taste shift brings it
-// back on its own — the whole point of a snooze over a dismissal (#2374).
-const (
-	defaultSnoozeDays = 90.0
-	maxSnoozeDays     = 365.0
-)
+// maxSnoozeDays caps a client-supplied duration. The DEFAULT is not here: it's
+// a DB-backed knob on the admin tuning card (rule #25), read per request via
+// recSettings.Discover().SnoozeDays. See #2377.
+const maxSnoozeDays = 365.0
 
 // snoozeRequest is the POST body. Both fields are optional in the JSON sense
 // (an absent body snoozes for the default), but Name is required in practice:
@@ -158,7 +166,7 @@ func (h *handlers) handleSnoozeSuggestion(w http.ResponseWriter, r *http.Request
 	}
 	days := body.Days
 	if days <= 0 {
-		days = defaultSnoozeDays
+		days = h.recSettings.Discover().SnoozeDays
 	}
 	if days > maxSnoozeDays {
 		// Clamp rather than reject: a client asking for longer than we allow