Fixes #1055
Problem
Removing a download from the Activity page could remove a different, pre-existing torrent from qBittorrent — and, with "delete files" on, delete that unrelated torrent's data. In the report, Listenarr had grabbed hash c86d5412… but removal deleted 82e3f9ad… (an unrelated torrent for the same book, added a month earlier).
Root cause
The grab persists the hash it added (DownloadClientMetadataUpdater.ApplyClientSpecificId), but queue reconciliation then overwrote it. PersistDiscoveredClientIdentifiersAsync writes the matched queue item's id onto the download whenever it differs from what's stored. A second torrent for the same book title-matches the download (GetMatchScore → 2, title), so the recorded ClientDownloadId/TorrentHash was replaced with that unrelated torrent's hash. DownloadRemovalWorkflow then resolved removal to the wrong hash and deleted it.
Fix
Queue discovery now only fills a missing identifier and never overwrites a recorded one. If the matched queue item's id differs from the identifier already stored on the download, the stored value is kept (the match was by title and may belong to an unrelated client download). A stable torrent infohash captured at grab time is therefore never rebound to a title-matched torrent, so removal always targets the correct one.
First-time discovery for downloads that have no recorded identifier is unchanged (the existing artist-aware/title-match persistence tests still pass).
Testing
New regression test: a download carrying its grabbed hash, with a pre-existing torrent of the same title (different hash) in the client queue, keeps its hash and never writes the pre-existing one. All existing DownloadQueueServiceReconciliationTests pass (30/30).
Note / possible follow-up
This closes the reported data-loss path (the overwrite). First-time discovery can still bind a download that has no grabbed hash to a title...
Automated Canary build