Fixes #963.
EfRemotePathMappingRepository injected a scoped ListenArrDbContext directly and shared it across all reads in a scope. During download polling, DownloadClientGateway fans out Task.WhenAll over every queue item, each calling RemotePathMappingService.TranslatePathAsync several times, so many GetByClientIdAsync reads run concurrently on that one context / SQLite connection. That tears down an active statement mid-query, poisons the pooled connection, and every later query — including library search — fails until restart.
Change
Convert the repository to the per-operation IDbContextFactory<ListenArrDbContext> pattern already used across the codebase (e.g. EfDownloadProcessingJobRepository). Each read/write gets its own short-lived context/connection, so the existing download fan-out is safe as designed. No behavior change.
Why the suite missed it
Every persistence/concurrency test uses ;Pooling=False; production leaves pooling on. Added a concurrent-read regression test to RemotePathMappingServiceTests (64 parallel GetPathMappingByClientAsync for one client), which fails against a shared context and passes with the factory.
Tests
RemotePathMapping suite (21) + DownloadClientGateway/DownloadQueue (49) green; full build clean.
Automated Canary build