feat: add native Slskd download client

[sean-gordon]

Summary

• adds Slskd as a first-class native download client
• routes ordinary downloads using explicit default, priority, and fallback settings
• performs bounded asynchronous Soulseek search and durable batch monitoring
• imports exact successful files into canonical author/title directories
• finalizes only validated isolated staging after successful import
• includes portable Linux, Windows Docker Desktop, and native deployment guidance

Safety and compatibility

• reserves downloads before external side effects to prevent duplicate batches
• preserves multi-chapter audiobook sets
• requires explicit terminal success for every transfer
• rejects unsafe paths and preserves partial, failed, or unverifiable staging
• leaves existing torrent and Usenet client behavior unchanged

Verification

• Backend: 1,232/1,232 passed
• Frontend: 392/392 passed
• Frontend production build and type-check passed
• Official Dockerfile build passed
• Architecture guards and git diff --check passed
• Baseline-aware sensitive-data and private-path audit passed

Documentation

• docs/download-clients/slskd.md
• docker-compose.slskd.example.yml

[therobbiedavis]

#717 changes DownloadImportService destination planning, durable directory ownership, audiobook operation locking, and the rule that download-client source paths are external filesystem identities. This Slskd feature remains distinct, but please rebase on #717 and preserve those contracts when resolving the import-service overlap: do not normalize client-reported source identities as user paths, and route newly created library destinations/companions through the ownership-safe import path.

[m4bard]

Cross-reference, since neither thread mentions the other yet: #465 and #785 both add slskd support, and they cover different halves of it.

#465 registers SlskdSearchProvider as an IIndexerSearchProvider alongside the Newznab and Torznab providers, with Implements => [Implementation.Slskd], so slskd results arrive as ordinary indexer results and go through scoring and manual grab.

#785 adds no user-facing indexer. SlskdDownloadService runs its own Soulseek search inside the submission path, and SlskdAdapter.AddAsync throws unconditionally, so slskd cannot receive a manually grabbed release there.

Both claim the "slskd" download-client type, so only one can register as written.

One upstream API detail that touches both, checked against slskd's own source rather than its docs. POST /api/v0/transfers/downloads/batches does not exist in TransfersController.cs at tag 0.25.1 and does exist at 0.26.0, where the per-user enqueue route also picks up an [Obsolete] marker. #785 uses the batch route, so it needs slskd 0.26.0 or newer, and I could not find that minimum stated in the PR body or in the docs page it adds. #465 uses the per-user route, which 0.26.0 still serves.

Both need a rebase onto #717 anyway, so deciding whether the indexer half and the client half land together or separately is cheaper now than after one of them merges.