fix: the taste arm round-robins across taste artists, and tag ties follow the order seed (#3880)

Measured on the operator's library (26,005 tracks, pool scale 2.28): the
arms the library scale grows all have far more rows than it asks for, and
two arms collapsed whatever their limits were.

- taste_overlap ordered by weight then track id, so the strongest taste
  artist's catalogue filled it: 20 tracks of saib. (197 tracks) out of 174
  taste artists, the same lowest-id tracks every time. It now takes one
  track per taste artist, strongest first, md5-seeded, as similar_artists
  does since #5297.
- tag_overlap broke ties in no order. A one-tag seed ties 7,804 tracks,
  and the LIMIT took whichever Postgres reached first, which the order
  seed did not control. Ties now follow md5(id || seed).
- library_scale.go records the per-arm measurement beside the reference
  size it leaves as is.

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

internal/recommendation/library_scale.go

@@ -34,9 +34,21 @@ const (
 	//
 	// ASSUMED, NOT MEASURED. The size the v1 constants were actually tuned
 	// against is unrecorded; 5,000 is a plausible mid-size library and a
-	// deliberately conservative place to start growing. #3879 should replace
-	// this with the real number, and until it does, this constant is the
+	// deliberately conservative place to start growing. This constant is the
 	// single thing to change.
+	//
+	// Measured on the operator's library, 26,005 tracks (scale 2.28), for the
+	// 15 most-played seeds and two Moe Shop tracks (#3880, 2026-10-21):
+	//   lb_similar       0–6 edges (3 of 17 seeds have any): never reaches
+	//                    even the base limit, so scaling it costs nothing
+	//   similar_artists  860–6,307 tracks over 7–33 artists: always full
+	//   tag_overlap      4,658–19,658 tracks: always full
+	//   likes_overlap    193–497 liked tracks sharing a tag: always full
+	//   taste_overlap    20,045 tracks over 174 artists: always full
+	//   coplay           0 rows: a single-user server
+	// So the arms the scale grows all have far more rows than it asks for, and
+	// the tuned-against size cannot be recovered from data; the number stays
+	// until a library shows a scaled arm running dry or a pool too slow.
 	libraryScaleReference = 5000
 
 	// maxLibraryScale bounds growth so a very large library does not turn