test(metrics): target deltas by test id, not by glyph — #2495

Two CI failures, both in my own new tests, both informative.

settings: queryByText(/≈/) matched the LEGEND explaining the glyph rather
than a delta, so the "no delta" case failed on the explanation being
present. Delta spans now carry data-testid so a test can name what it
means instead of pattern-matching prose that sits next to it.

tuning: getByText("40%") found two elements. testing-library matches an
element and its OWN direct text nodes, so the skip cell still matches
"40%" despite the trailing play-count span — and discover late-week
completion is also 40%. Genuinely ambiguous now; assert the count.

web/src/routes/admin/tuning/tuning.test.ts

@@ -200,10 +200,13 @@ describe('Admin tuning page', () => {
     // Radio's latest week: 40% skip over 15 plays; Discover's: 60% over 5.
     expect(screen.getByText('/15')).toBeInTheDocument();
     expect(screen.getByText('/5')).toBeInTheDocument();
-    // Completion columns are unchanged and still bare percentages — radio 70%,
-    // discover 40%.
+    // Completion columns are unchanged and still bare percentages — radio 70%.
     expect(screen.getByText('70%')).toBeInTheDocument();
-    expect(screen.getByText('40%')).toBeInTheDocument();
+    // '40%' is now genuinely ambiguous: radio's latest SKIP rate and discover's
+    // latest COMPLETION are both 40%. testing-library matches an element's own
+    // direct text nodes, so the skip cell still matches despite its trailing
+    // play-count span. Assert the count rather than pretending it's unique.
+    expect(screen.getAllByText('40%')).toHaveLength(2);
     // The window/last-week distinction has to be visible in the headers, or the
     // Plays total reads as the denominator of the skip rate. That misreading is
     // what #2495 was filed over.