feat(crossseed): check Source instances on adds into a Cross-seed instance

Parent

#3256

What to build

PR 2. Every cross-seed add into a Cross-seed instance also checks the hashes on its Source instances, so a torrent that the library side already has never lands on the Cross-seed instance too. The same cross-seed always gets its own link tree, whatever order qui finds the matches in. A seeded search does not start while the Cross-seed instance is unavailable.

Acceptance criteria

• The per-candidate add step, when the receiving instance is a Cross-seed instance, uses the shared Source instance hash check from the Dir Scan ticket. A disabled Source instance is skipped. An offline one fails the add with "instance unavailable", names it, and tells the user to enable it or clear its route. RSS retries the item.
• Before the candidate loop, qui sorts the candidates once with a stable sort, so that a Source instance's candidate runs before its Cross-seed instance's candidate.
• The hash checks before a download (the RSS infohash precheck, interactive search marks, Gazelle skip checks, Dir Scan search prechecks) keep checking the Source instance only. The add step stops a duplicate after one extra download.
• The webhook check endpoint matches by name and reads no hashes, so it does not change.
• A seeded search run on an instance with a route makes sure that the Cross-seed instance is available before it starts. If it is not, the run does not start and reports why. A completion search writes no search history, so it does not change.
• Tests:
  • A match on the Cross-seed instance checks its Source instances' hashes. A disabled Source instance is skipped, and an offline one fails the add.
  • The candidate sort puts a Source instance's candidate before its Cross-seed instance's candidate.
  • A seeded search run does not start when the Cross-seed instance is unavailable.

Out of scope

• Checking the Cross-seed instance in the hash checks before a download.
• Hash checks on Source instances for the export automation, torrent list adds, and backup restore.
• A setting that skips a cross-seed when any other instance already has it (#2103).

Rules for every ticket of #3256

• "Unavailable" means one of these: offline, disabled in qui, or (for an add or a directory listing only) older than qBittorrent 5.0 (WebAPI 2.11.2). Use the shared availability check from the route storage ticket. Do not write a new one.
• Tests talk only to local fakes and temp folders, never to a real host. Each new test fails before the change and passes after it.
• No user-facing text mentions SSH. No text calls the Cross-seed instance "remote", because "remote instance" means an SSH instance. An error for an instance that is in remote mode can say "remote instance".
• If the ticket changes the API, update internal/web/swagger and make sure that make test-openapi passes.
• Glossary terms: Cross-seed instance (the instance that receives the cross-seeds found on another instance) and Source instance (an instance that names a Cross-seed instance and holds the matched torrents). Do not say "target instance" or "library instance" for these.
• Delivery: tickets for PR 1 land on one integration branch that becomes PR 1. Tickets for PR 2 land on a second branch that becomes PR 2, after PR 1 merges. Do not merge one ticket to develop alone.