fix(library): open track details by path, not from the whole library

Track details from the queue, a playlist or a smart playlist looked
the track up in libraryStore's whole-library array, and returned
silently when it had not loaded, so the menu item did nothing. That
dependency is also why every track was fetched eagerly at startup
(20.5 MB at 26k tracks).

GetTracksByPaths answers for the paths in hand, and trackCache holds
the answers: bounded, coalesced into one call per task, and forgetting
what the retag, removal and scan events name. Every opener, and
track-details' own refresh after a save, go through it. A source sweep
pins the whole-library array to the store and the Tracks view.

Closes #279

frontend/bindings/yellowjacket/backend/library/library.ts

@@ -222,6 +222,21 @@ export function GetTracksByGenre(genre: string, libraryID: number): $Cancellable
     return $Call.ByID(1674220245, genre, libraryID);
 }
 
+/**
+ * GetTracksByPaths returns whole tracks for the given file paths, in
+ * the order asked, dropping any path that is not in the library.
+ * 
+ * It is how the frontend resolves the tracks a surface is actually
+ * showing (#279).  Track details from the queue, a playlist or a smart
+ * playlist used to look the path up in the whole library's track
+ * array, which had to be loaded first — so it was fetched eagerly at
+ * startup, 20.5 MB at 26k tracks, to answer questions about a handful
+ * of rows.
+ */
+export function GetTracksByPaths(paths: string[] | null): $CancellablePromise<$models.Track[] | null> {
+    return $Call.ByID(3966945290, paths);
+}
+
 /**
  * IsScanActive returns whether a scan is currently running.
  */