Fix TorrentRunner infinite crash loop on duplicate download path (#1033)

[websterwh]

One unfetchable file in a multi-file torrent put TorrentRunner into a permanent crash loop (~8 exceptions/sec, 29 GB of logs reported). Root cause: when a download with RetryCount > 0 refreshed its link from the provider, UpdatePath could write a restricted link that already existed on a sibling row, violating the unique (TorrentId, Path) index. Because the scoped DataContext shares one change tracker per tick, every subsequent save replayed the failed update — so the download could never be marked errored and TaskRunner hot-looped forever.

Changes:

• DownloadData.UpdatePath skips the write (with a warning) when another download of the same torrent already uses the path, detaches the entity on concurrent duplicate violations so the context can't be poisoned, and returns whether it persisted
• UnrestrictLink only adopts the refreshed path if it was actually persisted; otherwise it proceeds with the stored path so normal bounded retry/error handling applies
• Recovery code inside Tick()'s catch blocks is now fault-tolerant so one torrent's bookkeeping failure can't escape the tick and starve torrents queued behind it
• TaskRunner backs off exponentially (5s → capped 300s) after consecutive tick failures instead of re-ticking every second — covers any persistent DB error, including the FOREIGN KEY variant in Repeated SQLite Error 19: 'FOREIGN KEY constraint failed'. with lockup #906
• Regression tests in DownloadPathCollisionTests reproduce the exact collision + poisoned-change-tracker scenario against real SQLite