Add torrent acquisition API client

[TheusHen]

Summary

This adds a typed acquisition API layer and a new Torrent & automation settings screen for the new torrent and automation endpoints.

It can register supported integrations, search releases through configured indexers, submit magnet/torrent releases to a selected download client, and trigger native commands in Readarr and other Arr applications. The new screen is available from Profile → Storage → Torrent & automation.

Implementation notes

• Added endpoint and release models, including magnet recognition.
• Added authenticated API calls for endpoint configuration, release search, release submission, and Arr commands.
• Added a small model test covering magnet releases.
• Added a route and settings entry point for managing torrent and automation integrations in the app.

Validation

• Formatted the new Dart files with dart format.

Flutter is not installed in this environment, so Flutter tests and full package analysis could not be run here.

[Eoic]

Thanks for starting this integration. The server-mediated direction makes sense, but the current implementation is still a partial prototype. Before merging, please complete the opt-in lifecycle, integration management, torrent-only scope, search/submission UX, and Arr actions.

The feature should be disabled by default. A user can enable it under Profile → Storage, after which the management entry becomes visible. The route must enforce the setting and confirm that the active Papyrus server exposes the acquisition API; there is no hosted/self-hosted distinction.

For the initial torrent-only implementation, support torrent indexers, qBittorrent/Transmission/Deluge, and concrete Arr actions. Please remove Usenet-specific options.

Because the Papyrus server mediates these integrations, the backend contract must also validate endpoint URLs and store credentials securely.

Please resolve the authentication lifecycle and HTTP client ownership issues, add complete loading/error states, expand test coverage, and get formatting, analysis, and the full test suite passing in CI.

[TheusHen]

Addressed the requested lifecycle and scope cleanup in the client PR.

What changed:

• Torrent acquisition is now opt-in and disabled by default under Profile -> Storage.
• The management entry only appears after enabling the setting, and the /acquisition route redirects back to Profile when disabled.
• The acquisition page checks the active Papyrus server for /v1/acquisition/capabilities before loading management UI.
• Removed Usenet/Newznab from the client-side options and kept the initial scope to torrent indexers, qBittorrent, Transmission, Deluge, and Arr apps.
• Reworked the page into a fuller management/search/submission flow with loading, empty, error, retry, edit, remove, enable/disable, torrent search, send-to-client, and concrete Arr command actions.
• Fixed auth lifecycle by using the existing fresh-token flow for acquisition calls instead of reading a raw access token from the provider.
• Fixed HTTP client ownership by making the acquisition client disposable and owned by the page lifecycle.
• Added model/API/router/profile tests for capabilities, opt-in routing, HTTP calls, and Profile visibility.

Server-side follow-up is in PapyrusReader/server#4: endpoint URL validation, encrypted credential storage, torrent-only capabilities, and Newznab rejection were added there.

Validation run locally:

• dart format on changed client files
• server: ruff + mypy on changed acquisition/security files
• server capabilities runtime smoke check

Could not run full Flutter analysis/tests locally because Flutter SDK is not installed in this environment. Could not run backend pytest fully because the local Postgres on 127.0.0.1:5432 refused connection. Both should be covered by CI once the PR branches run there.