fix(automations): keep other actions off torrents the run deletes

Description

In one automation run, a torrent that a rule deletes could still get other writes. Category and move expansion, both cross-seed and group, added it to setCategory and setLocation. A cross-seed pulled into an include-cross-seeds delete still got its own move, category, tags and other actions. On qBittorrent 5.0.5 to 5.2.3, a delete with files that arrives while that torrent's move is running leaves the data at the move destination with no torrent (#2998).

This PR settles the delete set first, hardlink re-check included, and keeps every other action and expansion off it, in live runs and dry runs.

• applyRulesForInstance builds the delete set in its own pass over the desired states, runs blockedDeleteCandidates, and only then builds the other batches. A delete trigger still loses its own actions. A torrent pulled into another torrent's delete now loses them too.
• Category and move expansion skip torrents in the delete set, both in applyRulesForInstance and in recordDryRunActivities. Strict group eligibility still counts the deleted member.
• The hardlink re-check runs before the other writes instead of just before the delete. It gets its own ApplyTimeout, because the context at that point has no time limit. A candidate it blocks is not deleted, and expansion can still include it.
• Docs: in automations.md, one "Delete wins" bullet in "Processing order", a line each in "Action expansion" and the Category and Move options, the hardlink skip in the Delete section, and the separate dry-run pass in the dry-run section.
• The test brings its own stub qBittorrent (newWriteStubService), which overlaps newDryRunParityService here and newStubService in #2999. Whichever of this PR and #2999 merges second moves the tests onto one stub.
• #2999 edits the same "Processing order" list in automations.md. Whichever merges second combines its delete sentence with the one this PR adds.
• Not covered here: actions on a later run while an earlier run's move is still copying (#3005).

Fixes #2998

Behaviour change

• A torrent that a run deletes is no longer moved or re-categorised in that run by another torrent's cross-seed or group expansion. Before, qui sent the move or the category change and then the delete.
• When a delete pulls in other torrents (deleteWithFilesIncludeCrossSeeds, include hardlinks, or a keep-files group delete), those torrents get no actions from other rules in that run. That covers limits, pause, resume, recheck, reannounce, auto management, tags, category, move, external program and export.
• With groupId set, a move or category change still reaches the other members of the group when one member is deleted.
• The moved and category activity counts no longer include deleted torrents. A dry run of a delete rule and a move rule lists each deleted torrent only under delete.
• The hardlink re-check of a delete candidate now has its own time limit (ApplyTimeout, 60 s by default). Before, it shared one limit with every other write in the run, so slow writes could use it up, and the re-check then held back the deletes. Now slow writes no longer hold back deletes, and the worst-case time for one instance's run is two ApplyTimeouts instead of one.

Users do not need to change anything.

How has this been tested?

Live on qBittorrent 5.2.3 (official image), with qui built from this branch. Synthetic 256 MiB single-file torrents, moves across two mounts, and a proxy that logs every write qui sends. The develop behaviour for the same cases is in #2998.

TestApplyRules_TorrentTheRunDeletesGetsNoOtherAction covers every row of #2998, live and dry run, plus a torrent pulled into a keep-files group delete through another rule's tracker pattern. On develop the bug rows fail; two rows are guards that pass on develop and each fail on one wrong fix:

• "a deleted member that fails the move condition still makes the group ineligible" fails if deleted members are filtered out before the group eligibility check (live and dry run);
• "a delete the hardlink re-check blocks ..." fails if blocked hashes stay in the delete set, or if a blocked trigger gets its own actions back.

I ran 12 mutants of service.go at 86806231 and the test killed all of them. Each mutant did one of these:

• dropped one of the seven delete-set checks (pulled-in torrents; category, group move and legacy move, each in the live and the dry-run path);
• dropped the guard that keeps a blocked trigger's own actions off;
• kept blocked hashes in the delete set;
• filtered deleted members out before group eligibility (live and dry run);
• recognised a pulled-in torrent only through include-cross-seeds instead of through the whole delete set.

Performance

• Affected path: applyRulesForInstance. It makes one more pass over the desired states and one map lookup per expansion candidate. The hardlink re-check moves earlier and reads the same files.
• Workload: a temporary benchmark, not committed. 10,000 torrents in 5,000 cross-seed pairs. 500 are tagged for a keep-files delete. 2,500 are tagged for a move with cross-seed expansion and a category change with includeCrossSeeds. It is a live run against an HTTP stub qBittorrent with no activity store.
• Method: base develop e533d493 against 84df957e. Later commits change only a comment, a test and the docs. Each test binary was built once. They ran interleaved, 8 pairs of 20 iterations each, without -race, in podman golang:1.27 on a 5-CPU VM. Other sessions' field-test containers were running on the VM at the time; the interleaving evens out their load.
• Results (measured, medians of 8):

• Conclusion: no regression. Head does less work because the 500 deleted torrents are no longer moved or re-categorised. The worst case grows by one ApplyTimeout (see Behaviour change), and only when the re-check itself runs into its timeout.

Checklist

• My PR title follows the Conventional Commits format (it becomes the squashed commit message)
• If this changes the database schema, I have added migrations for both SQLite and PostgreSQL (no schema change)
• I completed the mandatory performance checks and recorded the outcome in Performance

AI disclosure

Yes. Claude Code (Claude Opus 5.5) wrote most of the code, the tests and this description.

Summary by CodeRabbit

• Bug Fixes

  • Automation runs now exclude torrents selected for deletion from other actions, including moves, category changes, and tags. This also applies to torrents included through group or cross-seed expansion.
  • If a hardlink change blocks a live deletion during re-check, the torrent is not deleted that run and may still be included in expansions, but receives none of its own other actions. It can be reconsidered on the next run.
  • Dry-run and live rules execute separately, so dry runs do not observe live-rule effects from the same cycle. Dry runs do not repeat the hardlink re-check.

• Documentation

  • Clarified deletion precedence, its effects on actions and expansions, and how deleted members count in strict group checks.