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.

web/src/lib/api/metrics.ts

@@ -4,6 +4,20 @@ import { api } from './client';
 // Mirrors internal/api/me_recommendation_metrics.go: raw play sources are
 // bucketed server-side into stable surface families, grouped by intent, and
 // anchored by the manual-plays baseline (milestone #127).
+// A difference from the baseline, with its uncertainty (#2495). Both figures
+// are already in percentage points — the server does the arithmetic so both
+// clients read the same numbers.
+//
+// `distinguishable: false` means |delta_pp| < margin_pp: the delta cannot be
+// told apart from zero, however large it looks. That distinction is the whole
+// point of this type — `low_confidence` answers "is this worth showing?", which
+// is a much lower bar than "is this worth acting on?".
+export type MetricDelta = {
+  delta_pp: number;
+  margin_pp: number;
+  distinguishable: boolean;
+};
+
 export type SurfaceMetric = {
   key: string;
   label: string;
@@ -12,6 +26,10 @@ export type SurfaceMetric = {
   skip_rate: number;
   avg_completion: number;
   low_confidence: boolean;
+  // Absent on the baseline row itself, and whenever the samples are too thin
+  // for a margin to mean anything.
+  skip_delta?: MetricDelta;
+  completion_delta?: MetricDelta;
   // Present when the surface's builder stamps pick-kind provenance and
   // the window holds attributed plays (#1249, generalized #1270): For
   // You's taste/fresh split, Discover's candidate buckets, the tiered