feat(metrics): publish margin of error on every delta — #2495, #2524

The metrics card had one volume threshold doing two jobs.
recMetricsLowVolume = 20 is a DISPLAY floor — below that a skip rate is
anecdote — but the card then presented deltas as though it were also a
DECISION floor. Those differ by an order of magnitude: detecting the ~13pp
differences that matter needs ~133 plays per arm for 80% power at a=0.05.

So Discover's taste-matched (59 plays) and random-unheard (70) both rendered
as full-confidence rows with a bold delta beside them, and that comparison
sits at p ~ 0.06. The card said "signal"; the arithmetic said "maybe". It
produced a recommendation the data didn't support, and any reader with the
same numbers would have made the same call.

Deltas now carry a 95% margin of error and a `distinguishable` flag, computed
server-side so both clients read the same arithmetic instead of each
re-deriving it. Skip rate is a two-proportion difference; completion is
Welch, which needs a variance — hence completion_sqsum in the query. It is
the sum of squares rather than stddev_samp on purpose: raw source rows are
merged into surface families in Go, and sums of squares combine across groups
exactly whereas standard deviations cannot.

recMetricsLowVolume is untouched. "Too thin to show" and "too thin to act on"
are different questions.

Web renders an indistinguishable delta as dimmed and prefixed "≈", with the
range on hover and a legend explaining the glyph. Colour is withheld unless
the delta clears its margin — colouring noise red is what made the old card
misleading. Breakdown rows go through the same path; those are the thinnest
samples on screen and where the old card misled most.

Also fixes the admin trends view, which had the same problem worse: its
"Latest skip"/"Latest completion" columns are one WEEK while the adjacent
Plays column is the whole window. I misread exactly that and briefly
concluded Deep cuts was the worst surface, from ~17 plays in a single week —
over 180 days it is one of the best. Headers now name their period and the
skip cell carries that week's play count.

#2524: resolveArtist now recognises a duplicate-MBID unique violation as the
expected condition it is, matching resolveAlbum. Two rows mapping to one
MusicBrainz artist is a merge candidate, not a fault; without the branch it
logged a generic warning plus a Postgres ERROR line on every scan, which
teaches an operator to ignore database errors.

internal/library/scanner.go

@@ -414,8 +414,21 @@ func (s *Scanner) resolveArtist(ctx context.Context, q *dbq.Queries, name, mbid
 				ID:   existing.ID,
 				Mbid: &m,
 			}); uerr != nil {
-				s.logger.Warn("library scan: heal artist mbid failed",
-					"artist_id", existing.ID, "err", uerr)
+				if isUniqueViolation(uerr) {
+					// Another artist row already owns this MBID — two rows that
+					// should be merged (usually two spellings of one name).
+					// Expected, not a fault: leave NULL and let the operator
+					// merge. Mirrors resolveAlbum, which has always handled it
+					// this way — without this branch the identical benign
+					// condition logged a generic warning plus a Postgres ERROR
+					// line on every scan, which teaches an operator to ignore
+					// database errors (#2524).
+					s.logger.Info("library scan: duplicate artist mbid (canonical row already owns it)",
+						"artist_id", existing.ID, "artist", name, "mbid", mbid)
+				} else {
+					s.logger.Warn("library scan: heal artist mbid failed",
+						"artist_id", existing.ID, "err", uerr)
+				}
 			} else {
 				existing.Mbid = &m
 			}