fix(qbittorrent): one unreadable torrent should not truncate the queue poll

[m4bard]

Summary

One torrent that cannot be mapped currently takes every torrent after it out of the same qBittorrent poll, and the poll still reports itself as a healthy live snapshot. This wraps the per-torrent body of the two loops in a try/catch so an unreadable torrent costs one torrent rather than the tail of the batch.

Full write-up, measurements and the alternative I did not take are in #829.

Changes

Fixed

• QbittorrentQueueFetchWorkflow.GetQueueAsync and QbittorrentItemFetchWorkflow.GetItemsAsync guard each torrent individually. A throw from MapQueueItem or MapDownloadClientItem is logged with the torrent hash and the loop continues, instead of unwinding to the outer handler that reports the client as possibly unreachable.
• The hash read in both loops checks ValueKind before calling GetString(), so a non-string hash cannot throw before the guard is entered.

Testing

QbittorrentAdapterTests gains a theory covering three token forms of a numeric field that the typed accessor rejects: a fractional number, a quoted number, and exponent form. Each asserts the torrents either side of the bad one still arrive and the bad one is absent. All three fail on c92e6089 and pass here.

The existing qBittorrent tests still pass: 55 total, 0 failed.

Reproduced end to end before and after against ghcr.io/listenarrs/listenarr:canary, using a stub that serves the qBittorrent WebUI routes the adapter calls, so the trigger is a response shape rather than a particular client state. The stub and the check are public, in the test-data repo linked from the issue.

Notes

I chose the per-item guard because SabnzbdQueueFetchWorkflow and TransmissionQueueFetchWorkflow already do exactly this, so qBittorrent converges on what its two closest neighbours share rather than adding a third approach.

There is a larger change I deliberately left out. #634 made the NZBGet readers tolerant of token form, which keeps the item and may hand downstream code a defaulted field, where Sabnzbd and Transmission drop the item and keep the rest of the poll. Doing the same to QbittorrentResponseMapper would keep the partly-downloaded torrent rather than dropping it. I left it out because on a list feeding import decisions a silently defaulted size or progress may well be worse than a torrent that is openly missing and logged, and because it is the more invasive of the two. That is your call rather than mine, and I have the tolerant readers on another branch if you would rather have them as well, or instead.

Two call sites with the same shape are untouched here and I have not reproduced either: QbittorrentTorrentLookupBuilder reads six fields through the same throwing accessors inline, and the item-fetch path feeds completion and import decisions, so a torrent lost there stops being considered for import at all. The guard in this PR covers the second of those; the lookup builder does not have one.