feat(web): show where each cross-seed went

Parent

#3256

What to build

PR 2. Run results, cross-seed activity, and season pack history show "found on A, added to B". The interactive apply dialog and the manual season pack assembly dialog say where the cross-seed goes before the user applies. The two new statuses have labels. The RSS and webhook instance fields read "Instances to search".

Acceptance criteria

• Run results, activity, and season pack history show the instance that held the match and the instance that received the add.
• The interactive apply dialog and the manual season pack assembly dialog say where the cross-seed goes, from the route of the instance that holds the match.
• The frontend types and i18n keys cover "Cross-seed instance cannot see the data" and "Cross-seed instance unavailable" in the apply dialog and the run results view. No raw backend status reaches the UI.
• RSS and webhook "Target instances" become "Instances to search" in every locale. The related keys that say "target instances" for the same field get the same rename. Field help uses FieldHelp.
• Component tests with mocked API responses for the status labels and the two-instance display.
• Read web/AGENTS.md first.

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.