Playback start and library recall are slow

[SolRaze]

From inbox — "the music playback and its recalling feature takes time to load content."

Suspects (pre-play path in Coordinator.start(_:)):

• LyricsResolver.resolve hits LRCLIB over the network before player.load.
• YouTube items re-extract every play (stream URLs expire) plus a youtubeSearch for Spotify/SoundCloud entries.
• LibraryStore.backfillArtwork() resolves every bookmark and opens every file after import.

Fix direction — start playback first; resolve lyrics/artwork async and attach when ready.

From verse-inbox.md.

[SolRaze]

Root cause found — two compounding things, both in the play path.

1. Playback start blocks on the network. Coordinator.start (Sources/App/Coordinator.swift:184-191) awaits lyric resolution and artwork extraction before player.load ever runs:

let lyrics = await LyricsResolver.resolve(...)        // up to 2 LRCLIB round trips
await Artwork.store(from: url, key: item.id.uuidString) // AVAsset metadata load
player.load(...)

So the tap-to-sound latency includes an LRCLIB lookup. Same shape on the YouTube audio path (Coordinator.swift:162).

2. Neither caches negatives. This is the worse half:

• LyricsResolver.resolve writes the cache only on a hit (Sources/Core/LyricsResolver.swift:25,33). A track with no lyrics anywhere re-hits LRCLIB on every single play — /api/get 404 then /api/search — forever.
• Artwork.store guards on exists(for:) (Sources/Core/Artwork.swift:39), which stays false forever when a file carries no embedded art, so it re-loads AVAsset metadata on every play.

This contradicts SPEC §3: "Cache resolved lyrics on disk keyed by the track's stable id so the car isn't waiting on network."

Fix sketch — start playback first and attach lyrics when they resolve (the player already publishes lyrics reactively, so the UI can catch up); write a negative-cache marker for both lyrics and artwork misses.

The suspects listed in the issue were right about LRCLIB-before-play and artwork backfill. Library recall (LibraryStore.init, Sources/App/Library.swift:67-79) decodes the whole library JSON synchronously on the main thread — likely the separate half of "recall is slow", worth measuring before changing.

[SolRaze]

Fixed the play-start half in 70d1ec5 (branch home-tab):

• player.load now runs before any network: lyrics + artwork resolve in a background task and attach late (Player.attach / NowPlaying.attach, no-op if the track changed meanwhile). Live Activity starts on late lyric attach.
• Negative caching both sides: empty .lrc = remembered lyrics miss, empty artwork .jpg = remembered no-art. No more LRCLIB round trips or AVAsset metadata loads on every replay of a lyric-less/art-less track. Manual Fetch Metadata clears the artwork marker (Artwork.invalidate).
• Checks: LyricsTests.testEmptyCacheFileIsANegativeHit, extended testArtworkExtractsEmbeddedCover — green on the 26.5 sim.

Still open here: the library-recall half (LibraryStore.init decodes the whole JSON synchronously on main) — measure before changing — and on-device confirm of tap-to-sound latency.