Retire the service worker's cache of the old, huge cover art

A DevTools trace recorded on musicdolphin put the whole question beyond argument:

  ImageDecodeTask      29,939 ms  x20   (~1.5 s each)
  Decode LazyPixelRef   3,924 ms  x20
  Decode Image          3,530 ms  x22
  Paint                    99.7 ms
  Layout                   77.3 ms
  all app JavaScript      <400 ms  across 22 seconds

Image decoding is not the largest cost on that page, it is very nearly the only one.

The covers should already have been small - the backend downscales to 640 px now - but
the page was still decoding them at 1920, 1600, 1400 px, with deliveryType
"cache-storage" on every one. The service worker caches cover art cache-first, keyed on
URL, on the premise that it is "immutable per album id". The id did not change; the
bytes did. So every client that had ever loaded a cover kept serving the 3000 px
original from its own disk and never asked the backend for the new one.

Renaming the cache is the retirement mechanism the worker already has - `activate`
deletes every cache that is not one of the two current names - so COVERS becomes v2,
with a note saying that changing how covers are produced means bumping it.

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

web/public/sw.js

@@ -4,7 +4,17 @@
 // cached answer for any of those would be a lie.
 
 const SHELL = "musikdelphin-shell-v1";
-const COVERS = "musikdelphin-covers-v1";
+// v2: the backend now downscales cover art to a 640 px long edge on its way into the
+// cache (MAX_COVER_PX in library/cache.py). The URL of a cover does not change when its
+// contents do, and the handler below is cache-first, so every client that had ever
+// loaded a cover went on serving the old 3000 px one from disk - a 9-megapixel decode
+// per card, which a trace on musicdolphin showed costing ~1.5 s each and dwarfing
+// everything else the page did. Renaming the cache is what retires them: `activate`
+// deletes every cache that is not one of these two.
+//
+// So: change how covers are produced, bump this name. "Immutable per album id" is true
+// of which album a cover belongs to, not of the bytes.
+const COVERS = "musikdelphin-covers-v2";
 
 self.addEventListener("install", (event) => {
   event.waitUntil(
@@ -42,7 +52,9 @@ self.addEventListener("fetch", (event) => {
   const url = new URL(request.url);
   if (url.origin !== self.location.origin) return;
 
-  // Cover art is immutable per album id and is the only heavy thing here.
+  // Cover art is cached aggressively - it is the only heavy thing here, and an album's
+  // art does not change from one load to the next. See the note on COVERS above for
+  // what to do when the way it is *produced* changes.
   if (url.pathname.startsWith("/api/albums/")) {
     event.respondWith(
       caches.open(COVERS).then(async (cache) => {