perf(library): pre-warm songs cache + off-thread fetch

[ghenry22]

Summary

Fixes the ~1s hang on the first browse to the Library Songs segment on a big library.

Root cause: the songs list was fetched synchronously on the JS thread during render (getAllSync + row→Child mapping), and the existing one-shot startup pre-warm was invalidated by the post-startup album-detail walk advancing songIndexStore.mutationCounter — re-arming the cold fetch before the user reached the segment.

Changes

• Off-thread async fetch — fetchAllSongsByTitleAsync() reads via expo-sqlite getAllAsync (background native thread) with the row mapping chunked (2000-row slices + setTimeout(0) yields), so neither stage blocks the JS thread. Sync variant kept for sync callers/tests; InternalDb gains getAllAsync.
• Non-blocking hook — useAllSongsByTitle returns the warm cache synchronously/instantly; a cold miss returns [] + loading and fills async, re-rendering when ready. In-flight fetches are shared (a cold mount racing the auto-warmer awaits the same fetch).
• Resilient auto-warmer — startSongLibraryCacheAutoWarm(): initial warm after startup interactions, then a debounced (2s) re-warm on every mutationCounter change, run on idle. Survives the album-detail walk that invalidated the old warm. Started from runDeferredStartup; removed the queueMicrotask warm in rehydrate.ts.
• UI — Songs list spinner now reflects the hook's loading.

Testing

• tsc --noEmit clean
• Full jest green (7012 tests, 360 suites; +4 async-fetch tests)
• On-device (big library, tablet/phone): first Songs browse instant after sync settles; brief spinner instead of freeze if browsed mid-sync; filters + pull-to-refresh intact