feat(automations): document, test and show the order a run applies actions in

Description

One automation run sends its actions in a fixed order, and every action sees the torrent as it was when the run started. This PR pins both rules with tests, shows the order in the rule editor, and documents it. Runs do not change.

• actionRunOrder in the automations package lists the order once. Only tests read it.
• TestApplyRules_SendsActionsInRunOrder runs a live pass against a stub qBittorrent. It checks the write requests for speed limits through move, and the activity rows for all 13 steps. External program and export are checked through their rows: with no external program service and an export to a missing instance, both record a row when they are dispatched.
• TestApplyRulesDryRun_ReportsActionsInRunOrder checks the dry-run report against the same list.
• TestApplyRules_DeleteDropsTheTorrentsOwnActions: rule A tags, rule B deletes; the deleted torrent gets no tag request, the other torrent does.
• TestApplyRulesDryRun_RulesSeeStartOfRunTorrent and TestApplyRules_ExportSeesStartOfRunTorrent: after rule A changes the category, a later condition on the old category matches, one on the new category does not, and Move and Export paths built from {{ .Category }} use the old category.
• The stub qBittorrent behind newDryRunParityService now takes a torrent list and records writes. The harness sets ApplyTimeout; with Config{} a live pass times out before its first write.
• ACTION_RUN_ORDER in web/src/lib/workflow-utils.ts mirrors the Go list. A Vitest test reads the Go source and fails when the two differ. It drives COMBINABLE_ACTIONS, getEnabledActions, the add-action selector and the empty-state selector.
• The editor renders Move between Category and External program, not last. The empty-state selector lists auto management after reannounce. The "Action" label (actions.title) has a help icon that explains the order and the start-of-run rule. Translations other than English are best effort.
• automations.md: "Processing order" now covers every action; new "Run order" and "Each action sees the torrent as the run started" sections.

With #2813, an export whose save path uses .CurrentSavePath does not run in the same run as a move; it waits for a later run. Whichever of #2813 and this PR lands second documents that.

Cross-seed and group expansion can still move or re-categorise a torrent that the same run deletes. That stays out of scope here and is tracked in #2998, fixed by #3006. #3006 also edits the delete sentence in automations.md and adds tests; whichever of the two lands second merges the two sentences and moves its tests onto one shared stub.

Overlap: #2825 adds a similar stub qBittorrent (qbitStub) to service_dryrun_parity_test.go and a renderDialog helper to WorkflowDialog.test.tsx, and inserts its queue position action after reannounce. Whichever of the two lands second merges the harnesses and adds the action to actionRunOrder and ACTION_RUN_ORDER; the order tests will fail until it does.

Fixes #2979

How has this been tested?

Field test on 346296b9 (later commits change only comments, docs and two translations): qui built from this branch, auth disabled, two unreachable instances, one rule with every combinable action.

• Editor sections, read from the DOM: Speed limits, Share limits, Pause, Resume, Force recheck, Force reannounce, Auto management, Tag actions, Category, Move, Run external program (added through the add-action menu), Export to instance.
• New rule, empty-state selector: the same order, then "Delete (standalone only)".
• The help icon next to "Action" shows the new text.

Mutation testing (each mutant shown failing the intended test):

• 30 backend mutants: every adjacent swap of the live steps from speed limits to move, both dispatch calls moved before the moves and after the deletes, the two dispatches swapped, every adjacent swap in recordDryRunActivities, the delete branch without continue, and the three snapshot mutations from the issue. 30 killed.
• 6 frontend mutants: either list reordered alone, Move rendered last, the develop empty-state order, a reordered add-action list, no help icon. 6 killed.

Performance

Backend: no runtime path changes. actionRunOrder is a package-level slice that only tests read.

Frontend: the dialog derives two short lists from a 13-entry constant (COMBINABLE_ACTIONS once at module load, getEnabledActions per render, as before) and renders one more tooltip. Bundle size at ee76e806 against develop 8a17b869, measured with pnpm build (node:24 container), wc -c and Apple gzip 479 at -9 over all 119 files in dist/assets/*.js:

Where the bytes went (raw, per chunk name):

• index-*.js, the entry script in index.html (WorkflowDialog and the English locale): -1,428. The hard-coded lists are gone; the new English string is included.
• useInstancePreferences-*.js, preloaded by index.html: +163. That is the 160-byte ACTION_RUN_ORDER literal plus 3 bytes of renamed minified identifiers.
• instances-*.js (the ten lazily loaded translations): +2,424, the new string in each.
• Six chunks differ by 5 bytes, from changed chunk hashes in their import paths.

Conclusion: first load shrinks by 1,265 bytes raw (index and the preloaded chunk together). All JS grows by 820 bytes gzip, the lazily loaded translations. No runtime cost.

Screenshots (for UI changes)

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 all of the code, tests, docs and translations, ran the checks, mutation tests and the live test, and wrote this description. Colin directed the work and made the design decisions. A second Claude Code session wrote the spec and reviewed and mutation-tested this branch before it opened.

Summary by CodeRabbit

• New Features
  • Automation actions run in a defined order shown in the workflow editor. A help note explains that actions use the torrent’s state from the start of the run; for example, an external program after a move receives the previous save path.
• Documentation
  • Clarified how matching rules prioritize or combine actions, including how delete affects other selected actions and how torrent state is evaluated during each run.