Use content_path and add savePath/path-wait

Always use qBittorrent's content_path as the canonical downloadPath and expose savePath on DownloadInfo instead of reconstructing paths from save_path + basename. Add path-waiting logic to the monitor: track consecutive pathWaitCount polls, re-queue the monitor with exponential-ish backoff while content_path remains outside save_path (to handle TempPathEnabled races), and give up after a configurable max attempts. Extend the MonitorDownload payload and JobQueue APIs to carry pathWaitCount. Organize-files processor now attempts to refresh the stored downloadPath from the download client and updates downloadHistory if the client reports a different path (applying path mapping). Update tests to reflect the new behavior and expectations.

src/lib/services/job-queue.service.ts

@@ -65,6 +65,7 @@ export interface MonitorDownloadPayload extends JobPayload {
   downloadClient: DownloadClientType;
   lastProgress?: number;  // Previous poll's progress (0-100) for stall detection
   stallCount?: number;    // Consecutive polls with no progress change (drives backoff)
+  pathWaitCount?: number; // Consecutive polls waiting for content_path to relocate to save_path
 }
 
 export interface OrganizeFilesPayload extends JobPayload {
@@ -567,7 +568,8 @@ export class JobQueueService {
     downloadClient: DownloadClientType,
     delaySeconds: number = 0,
     lastProgress?: number,
-    stallCount?: number
+    stallCount?: number,
+    pathWaitCount?: number
   ): Promise<string> {
     return await this.addJob(
       'monitor_download',
@@ -578,6 +580,7 @@ export class JobQueueService {
         downloadClient,
         lastProgress,
         stallCount,
+        pathWaitCount,
       } as MonitorDownloadPayload,
       {
         priority: 5, // Medium priority