docs: query comments say what each query selects and why, not how it came to be (#6277)

Rewrites the internal/db/queries comments to rule 32 and regenerates
dbq, whose doc comments and embedded SQL carry them. The bugs behind the
tiered mixes, the md5 order seed, the score bands and the round-robin
arms are restated as the constraint each one enforces; counts from one
library and stale cross-references are gone.

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

internal/db/queries/system_playlists.sql

@@ -1,4 +1,4 @@
--- Track picks here join `tracks ... AND t.missing_since IS NULL` (#2523): a
+-- Track picks here join `tracks ... AND t.missing_since IS NULL`: a
 -- seed or For-You candidate has to be something that can actually play. Note
 -- this only affects newly GENERATED playlists — already-stored system
 -- playlists keep their rows until the next daily rebuild, which is why the
@@ -6,7 +6,7 @@
 -- also serves user-curated playlists, where hiding a track the user added
 -- themselves would be wrong).
 
--- M7 #352 slice 2: system-generated playlist queries.
+-- System-generated playlist queries.
 
 -- name: ListActiveUsersForSystemPlaylists :many
 -- Active = had a play in the last 7 days. The cron iterates this list.
@@ -56,22 +56,22 @@ UPDATE system_playlist_runs SET in_flight = false WHERE in_flight = true;
 
 -- name: PickSeedArtists :many
 -- Top-12 most-engaged distinct artist candidates, tiered so the
--- "Songs like X" mixes never silently vanish (#1255): the old hard
--- 7-day window emptied the seed pool after a quiet week, and the
--- daily atomic-replace build then deleted every existing mix until
--- the user played something again. Same fallback shape as
+-- "Songs like X" mixes never silently vanish: a hard 7-day window
+-- would empty the seed pool after a quiet week, and the daily
+-- atomic-replace build would then delete every existing mix until the
+-- user played something again. Same fallback shape as
 -- PickTopPlayedTracksForUser (For You's seeds):
 --   tier 0  engagement in the last 7 days
 --   tier 1  (only if tier 0 empty) last 30 days
 --   tier 2  (only if tiers 0+1 empty) all-time
 --   tier 3  (only if 0-2 empty) liked artists with no play history
 -- All returned rows share one tier; produceSeedMixes maps it onto the
--- rule-#131 pick-kind ladder and stamps the built tracks, so metrics
+-- tiered pick-kind ladder and stamps the built tracks, so metrics
 -- can compare mixes seeded from fresh vs stale engagement.
 -- Score = unskipped-play count + 5 if user has liked the artist. The
 -- Go-side picker (pickSeedArtistsForDay) shuffles the 12
 -- daily-deterministically and takes songsLikeSeedCount (6) so the mix
--- set both rotates day-to-day and fills the dedicated Home row (#1491).
+-- set both rotates day-to-day and fills the dedicated Home row.
 WITH liked AS (
     SELECT gla.artist_id FROM general_likes_artists gla WHERE gla.user_id = $1
 ),
@@ -163,7 +163,7 @@ alltime AS (
 ),
 -- A likes-only read still joins tracks: a like outlives its file, and a
 -- seed whose file is gone points For You at something the user can't hear
--- (#2701). The other two tiers get the same filter from their play_events
+--. The other two tiers get the same filter from their play_events
 -- join.
 liked AS (
     SELECT gl.track_id AS id, 0::bigint AS c, 2 AS tier
@@ -206,7 +206,7 @@ SELECT COALESCE(
        FROM tracks t
        JOIN albums a ON a.id = t.album_id
       WHERE t.artist_id = $2
-        AND t.missing_since IS NULL  -- #2701: the play branch filters; this one must too
+        AND t.missing_since IS NULL  -- the play branch filters; this one must too
       ORDER BY a.release_date DESC NULLS LAST,
                t.disc_number NULLS LAST,
                t.track_number NULLS LAST,