feat(crossseed): make sure the Cross-seed instance sees the data before a routed add

Parent

#3256

What to build

PR 2. Before each routed add, qui asks the Cross-seed instance's qBittorrent to list the folder that holds one linked file. If the file is not there, qui removes the link tree it built, adds nothing, and reports "Cross-seed instance cannot see the data at ". A wrong mapping then never starts a download from zero.

Acceptance criteria

• After the tree build and the path mapping, and before the add, qui lists the folder that holds one linked file, after mapping, with the listing check from the Test route ticket.
• If the entry is missing, qui lists again 3 times over about 15 seconds. A ponytail: comment names this limit, because NFS can cache a folder listing for up to 60 seconds.
• In one run, after a check fails for a base folder, later adds under that folder list once and do not retry. The memory of failed folders lives for one run of each Trigger: an RSS run, a seeded search run, and one request for webhook, manual, and interactive apply.
• If the check fails, or the Cross-seed instance becomes unavailable after the tree build, qui removes what this attempt created, the same way the add failure rollback does today. The add fails with "Cross-seed instance cannot see the data at " or "Cross-seed instance unavailable".
• A new result status "Cross-seed instance cannot see the data" counts as a failure, so RSS retries the feed item on its next run.
• Tests drive the per-candidate step with a fake sync manager that answers the directory listing per instance, including an error answer:
  • A disc layout or a pack with subfolders passes the check.
  • A missing entry blocks the add with its status and removes the tree.
  • A late entry passes on a retry.
  • A second failure under the same folder in one run does not retry.
  • A listing error counts as "cannot see".
• Swagger updated, make test-openapi passes.

Out of scope

• Reaching the Cross-seed instance's files over SSH or through a backend.

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.