perf(library): load a collection when a view needs it, not at startup

All four collections were fetched at DOMContentLoaded and refetched on
every invalidation, whichever view was showing. On a 26 138-track
library the track list was 20.5 MB of that, and encoding it cost the
backend ~170 MB of transient allocation — paid by someone looking at
Home, which draws none of it.

- The store warms only albums, artists and genres, on idle after first
  paint: 1.6 MB together, and what made those views instant.
- A nav item prefetches on hover and on keyboard focus, which is the
  ~100 ms before the click that a cold open would otherwise wait.
- An invalidation refetches what something had loaded, and nothing
  else — a scan no longer loads the track list of a library whose
  Tracks view nobody has opened.
- `index.html`'s first-paint `<track-list>` is `view-hidden`, and
  `index.ts` no longer activates it: it is markup, not a decision about
  which view the launch lands on, and activating it was what fetched
  the whole list for a landing on Home. The track list itself loads on
  view activation, which the shell drives.

Measured on 50 000 tracks: backend RSS at rest 543 → 296 MB, peak 571 →
296 MB, Go heap held 361 → 125 MB, JS heap 31.8 → 18 MB, binding bytes
at rest 35.9 → 12.1 MB, heap after a browse 36.5 → 22.7 MB. Tracks
first open 26 ms; slowest view open 57 ms.

Closes #280

frontend/src/components/queue-panel/queue-panel.ts

@@ -1553,9 +1553,13 @@ export class QueuePanel
         indices: number[],
     ) {
         const queueTracks = this.queue.tracks;
-        const filePaths = indices
-            .map((i) => queueTracks[i]?.filePath)
-            .filter((fp): fp is string => fp != null);
+        const filePaths: string[] = [];
+
+        for (const i of indices) {
+            const path = queueTracks[i]?.filePath;
+
+            if (path != null) filePaths.push(path);
+        }
 
         await showBatchTrackDetailsForPaths(
             () => this.trackDetailsDialog,