Fix SQLite contention during import-list sync

[johoja12]

Summary

• serialize per-list fetch and parse processing
• skip unchanged import-list mappings and library-cleanup writes
• coordinate SQLite repository writes and extend the busy timeout to 5 seconds
• keep ImportListSync type-exclusive while allowing it to run alongside long-running refresh commands

Problem

Large import-list syncs created overlapping SQLite writer and reader windows. The prior queue-only patch avoided one collision but did not cover concurrent per-list processing or long refresh work.

Testing

• Focused datastore and import-list suite: 58 passed, 0 failed
• Release Core build: 0 warnings, 0 errors
• Production Radarr 4K validation: Indian, Kids, and Movies were enabled one at a time; each completed staged scheduled syncs alongside RefreshMovie with zero new database-is-locked or SQLite Busy logs.

[johoja12]

Updated with 7df4bfa: queue persistence now waits for an active exclusive command before writing command records. Added single and batch persistence regressions (11 focused command-queue tests pass) and built against Radarr 6.5.1.2032.\n\nProduction Radarr4K canary showed zero fresh SQLite lock errors. The enabled RadarrIndian sync then stalled in its remote-fetch phase, so it was paused again and the service was left healthy with all import lists disabled. This is distinct from the original concurrent SQLite writer failure.

[johoja12]

Follow-up production canary: enabling all three Radarr import lists still produced SQLite Busy errors, now traced inside FetchAndParseImportListService parallel list workers while syncing RadarrKids (ImportListMovieService.SyncMoviesForList). This is separate from command-queue persistence; the current patch prevents the latter but is not sufficient for all-list concurrency. I re-paused all three lists and verified a clean post-restart scheduler cycle with zero new locks.