Preserve qBittorrent content path for imports

[bigsaam]

Summary

• carry saved qBittorrent/RDT content_path metadata into import queue item resolution
• let the existing ContentPath translation/scanning fallback run when qBittorrent /torrents/files returns an empty list
• add a regression test for passing ClientContentPath to the download client gateway

Tests

• dotnet restore tests/Listenarr.Tests.csproj --source https://api.nuget.org/v3/index.json
• dotnet test tests/Listenarr.Tests.csproj --no-restore --filter FullyQualifiedName~DownloadItemServiceTests
• dotnet test tests/Listenarr.Tests.csproj --no-restore --filter FullyQualifiedName~DownloadClientGatewayTests

[T4g1]

The method is intended to "refresh" the knowledge Listenarr has about an ongoing download. Why would we want to add application data into the adapter reply ? If qBittorrent says there is no file, why do we want to assume otherwise ?

I know the DownloadItem service is designed to already override some information into the adapter but I believe we should remove that and leave the DownloadClientGateway handle that if needed
wdyt ?

[therobbiedavis]

The method is intended to "refresh" the knowledge Listenarr has about an ongoing download. Why would we want to add application data into the adapter reply ? If qBittorrent says there is no file, why do we want to assume otherwise ?

I know the DownloadItem service is designed to already override some information into the adapter but I believe we should remove that and leave the DownloadClientGateway handle that if needed wdyt ?

@T4g1 I agree. If this method is meant to refresh the import item from the client, then qBittorrent should remain the source of truth. Passing ClientContentPath from Download.Metadata into the adapter input lets stale Listenarr state override the current client response.

@bigsaam Unfortunately I don't align with this PR’s approach. If qBittorrent returns no files/content path, we should surface that as an unresolved import state and retry later or block with a clear reason, rather than scanning a remembered path.

[therobbiedavis]

@bigsaam I am going to close the PR. If you want to submit a PR that handles the underlying qBittorrent empty-files case separately by making it retryable or clearly blocked, while keeping the live client response as the source of truth, I would be receptive to that.

Thanks!