fix: always disambiguate same-named artists, remove score guard

The allSameScore guard prevented the LB popularity lookup from
firing because the blended scores differed slightly (40 vs 37)
even though both had zero index popularity. The small difference
came from different MB relevance scores (100 vs 93), not from
meaningful popularity data.

Removed the guard entirely — the LB lookup now always fires for
2+ same-named artists in tier 0. The cost is negligible (one POST
with 2-6 MBIDs) and the result is always correct.

backend/explore/explore.go

@@ -1123,8 +1123,8 @@ func (e *Service) boostNameMatches(query string, result *MBSearchResult) {
 // disambiguateSameNameArtists resolves ordering among artists
 // that share the exact same name as the query by fetching their
 // LB popularity.  This is a targeted micro-lookup (typically 2-6
-// MBIDs) that only fires when the index fast path left same-named
-// artists with zero popularity.
+// MBIDs) that only fires when the index fast path couldn't
+// meaningfully differentiate same-named artists.
 func (e *Service) disambiguateSameNameArtists(query string, artists []MBArtist) {
 	// Find the contiguous block of tier-0 same-name artists at the front.
 	var sameNameEnd int
@@ -1141,23 +1141,6 @@ func (e *Service) disambiguateSameNameArtists(query string, artists []MBArtist)
 		return // 0 or 1 same-name artists — nothing to disambiguate
 	}
 
-	// Check if they already have differentiated scores.
-	allSameScore := true
-
-	firstScore := artists[0].Score
-
-	for i := 1; i < sameNameEnd; i++ {
-		if artists[i].Score != firstScore {
-			allSameScore = false
-
-			break
-		}
-	}
-
-	if !allSameScore {
-		return // scores already differ — reranking handled it
-	}
-
 	// Collect MBIDs for the targeted LB lookup.
 	mbids := make([]string, 0, sameNameEnd)
 	for i := range sameNameEnd {