fix(library): a fully-missing album leaves the year axis too — #2702

Filed as a product decision, but the code had already made it: the genre
queries filter tracks.missing_since inside their EXISTS, so an album
whose every file had gone was ALREADY absent from genre while still
listed under its year — where opening it found nothing playable. The two
browse axes disagreed, and whichever answer won, one of them had to
change.

Hiding is the answer. Browsing is how you go looking for something to
play, and the rule for that case is to take it out of view; the admin
missing-files surface is where absence gets reported, with far more
detail than a silent gap in a grid. It also means changing the axis that
was inconsistent rather than the one that was already right.

All three year queries move together — index, list and count. That is
the invariant #367 needed care for at the genre level: if the index
groups differently from the filter, a year leads to an empty page, and
if the count disagrees with the list then "Load more" promises rows that
never arrive.

The predicate is "has at least one playable track", which also excludes
an album carrying no tracks at all. Same answer for the same reason —
nothing to play, nothing to browse to — and it is what genre has always
done, since an album with no tracks contributes no genres either.

That last part changed two existing tests, which had been seeding
trackless albums as a convenience. Their intent (undated albums never
appear in a range) is untouched; they now seed a track each, which is
what a real album looks like anyway. Two new tests pin the actual
behaviour: a fully-missing album leaves the axis while a half-missing
one stays, and the count agrees with the filtered list.

internal/db/dbq/browse.sql.go

@@ -38,6 +38,11 @@ SELECT COUNT(*) FROM albums
 WHERE release_date IS NOT NULL
   AND EXTRACT(YEAR FROM release_date)::int
       BETWEEN $1::int AND $2::int
+  AND EXISTS (
+    SELECT 1 FROM tracks
+     WHERE tracks.album_id = albums.id
+       AND tracks.missing_since IS NULL
+  )
 `
 
 type CountAlbumsByYearRangeParams struct {
@@ -56,6 +61,11 @@ const listAlbumYearsWithCount = `-- name: ListAlbumYearsWithCount :many
 SELECT EXTRACT(YEAR FROM release_date)::int AS year, COUNT(*)::bigint AS album_count
 FROM albums
 WHERE release_date IS NOT NULL
+  AND EXISTS (
+    SELECT 1 FROM tracks
+     WHERE tracks.album_id = albums.id
+       AND tracks.missing_since IS NULL
+  )
 GROUP BY year
 ORDER BY year DESC
 `
@@ -161,6 +171,11 @@ JOIN artists ON artists.id = albums.artist_id
 WHERE albums.release_date IS NOT NULL
   AND EXTRACT(YEAR FROM albums.release_date)::int
       BETWEEN $1::int AND $2::int
+  AND EXISTS (
+    SELECT 1 FROM tracks
+     WHERE tracks.album_id = albums.id
+       AND tracks.missing_since IS NULL
+  )
 ORDER BY albums.sort_title, albums.id
 LIMIT $4 OFFSET $3
 `
@@ -304,10 +319,22 @@ type ListGenresWithCountRow struct {
 // Browsing is a way of finding something to play, so a track that cannot play
 // should not shape it.
 //
-// Year queries below join albums only and are deliberately left alone: an album
-// is still a real release even if some of its tracks are gone. An album whose
-// EVERY track is missing will linger on the year axis; that's a narrower case,
-// tracked with the rest of the cleanup work.
+// The year axis filters too (#2702). It used to join albums only, on the
+// reasoning that an album is a real release even when some of its tracks are
+// gone — true, but it left the two browse axes disagreeing: the genre queries
+// above filter tracks.missing_since, so an album whose every file had vanished
+// was already absent from genre while still listed under its year, where
+// opening it found nothing playable.
+//
+// Hiding is the answer rather than showing-and-marking because browsing is how
+// you go looking for something to play, and the operator's rule for that case
+// is to take it out of view; the admin missing-files surface is where absence
+// is reported. It also means changing the axis that was inconsistent rather
+// than the one that was already right.
+//
+// The predicate is "has at least one playable track", so it also excludes an
+// album with no tracks at all. That is the same answer for the same reason:
+// nothing to play, nothing to browse to.
 // Genre browse index (#367).
 //
 // Genres live inline on tracks.genre as a delimited string, so this splits on