fix(QBittorrentProxyV2): accept empty body as auth success (qBit >= 4.5)

[csmarshall]

Summary

Port the qBit-auth-response handling from Radarr/Sonarr to bookshelf so all three forks treat modern qBittorrent the same way.

Bugs fixed

QBittorrentProxyV2.AuthenticateClient has two related bugs against qBittorrent 4.5+ that radarr and sonarr both already fixed but bookshelf hasn't pulled in:

1. Empty-body success is mis-reported as auth failure. qBit 4.5+ returns HTTP 204 No Content (empty body) on a successful /api/v2/auth/login instead of HTTP 200 with body "Ok.". The existing if (response.Content != "Ok.") treats "" as failure, so every successful login becomes a DownloadClientAuthenticationException.

2. HTTP 401 routed to the wrong exception type. A bad password from outside qBit's trusted-subnet whitelist returns 401 Unauthorized. The existing HttpException catch only converts 403 Forbidden to DownloadClientAuthenticationException; 401 falls through to a generic DownloadClientException ("Failed to connect"), giving users the wrong error category.

Symptom

Persistent Failed to authenticate with qBittorrent log spam in current bookshelf releases against a known-good username/password pair — including configurations where Radarr and Sonarr on the same machine, with the same credentials, work fine.

2026-05-13 20:27:08.4|Error|QBittorrent|Unable to authenticate
[v0.4.20.129] NzbDrone.Core.Download.Clients.DownloadClientAuthenticationException: Failed to authenticate with qBittorrent.
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxyV2.AuthenticateClient(...) :line 444

Reproduces deterministically against linuxserver/qbittorrent:5.2.0 (qBittorrent 4.5+). Hand-tested with wget against /api/v2/auth/login from inside the bookshelf container:

correct password → HTTP/1.1 204 OK, content-length: 0, set-cookie: QBT_SID_<port>=...
wrong password   → HTTP/1.1 401 Unauthorized

Fix

Mirror Radarr's QBittorrentProxyV2.cs (Sonarr's copy is byte-identical in the relevant block):

                 catch (HttpException ex)
                 {
-                    _logger.Debug("qbitTorrent authentication failed.");
-                    if (ex.Response.StatusCode == HttpStatusCode.Forbidden)
+                    _logger.Debug(ex, "qbitTorrent authentication failed.");
+
+                    if (ex.Response.StatusCode is HttpStatusCode.Unauthorized or HttpStatusCode.Forbidden)
                     {
                         throw new DownloadClientAuthenticationException("Failed to authenticate with qBittorrent.", ex);
                     }
                     ...
                 }
                 ...

-                // returns "Fails." on bad login
-                if (response.Content != "Ok.")
+                if (response.Content.IsNotNullOrWhiteSpace() && response.Content != "Ok.")
                 {
                     ...
                 }

The legacy "Fails." body still throws DownloadClientAuthenticationException via the non-empty/non-"Ok." path, so older qBit versions are not regressed.

Scope choice

The rest of QBittorrentProxyV2.cs has diverged ~90 lines from Radarr/Sonarr but most of that divergence is either correct-for-bookshelf (MusicCategory vs MovieCategory) or new features (ApiKey-based auth, AddTags()) that are orthogonal to this bug. Kept this PR tight to the auth-response handling so it's an obviously-safe, easy-to-review backport. Happy to do follow-up PRs for the new-feature bits if they're wanted.

Test plan

• Manually confirmed qBit's new response shape on linuxserver/qbittorrent:5.2.0 (qBittorrent 4.5+).
• Cross-checked the patch against Radarr's and Sonarr's QBittorrentProxyV2.AuthenticateClient — byte-for-byte equivalent in the changed region.
• CI to verify no regression in the existing test suite.
• Built locally: dotnet build NzbDrone.Core/Readarr.Core.csproj -c Release clean — 0 warnings, 0 errors.

[shafe123]

Possible duplicate of #158

[pennydreadful]

#170