Move pending jobs to default queue instead of deleting them

[reitblatt]

Context & Requests for Reviewers

Closes #1113.

Deleting an MRT queue called queue.obliterate({ force: true }), which
silently wiped every job in the queue regardless of status — waiting,
delayed, or actively being reviewed. Per the issue discussion and
@reitblatt's suggested approach,
this PR:

• Moves pending jobs (waiting/delayed/active) into the org's default queue
  (or default appeals queue, for appeals queues) before the source queue is
  obliterated, instead of deleting them.
• Updates the delete-queue confirmation modal to show the queue's pending
  job count and warn that those jobs will be moved rather than deleted.

Job migration is best-effort per job: if copying a particular job fails, the
failure is traced but queue deletion still proceeds (matching the existing
best-effort behavior around obliterate() failures below it).

Follow-ups called out in the issue — letting the user pick a different
destination queue, or configure an auto-action instead of always routing to
the default queue — are left for a later PR.

Tests

• Added a regression test in QueueOperations.test.ts: deletes a
  non-default queue containing pending jobs, asserts they land in the org's
  default queue, and asserts the deleted queue's DB row and Bull queue are
  both gone.
• (cd server && npm run test:prepush -- services/manualReviewToolService/modules/QueueOperations.test.ts) — 18/18 passing.
• npx tsc --noEmit clean in both server and client.
• npx eslint clean on all changed files.
• Manually reviewed the appeals-queue code path; there wasn't an existing
  fixture for appeal-job payloads to cover it with an automated test.

(Optional) Rollout Plan

None — additive and backwards compatible. No migration or config changes
required.

Checklist

Only check items that apply to this PR; leave the rest unchecked.

• If you changed anything user-facing (i.e. user interface or APIs):
  Did you update related docs?

• If the change is notable (refer to Keep a Changelog conventions):
  Did you update CHANGELOG.md?

• If you changed server/models/**/{ContentTypeModel,ActionModel,RuleModel,PolicyModel}.ts:
  Did you update the corresponding history tables and their triggers?

• If you changed db/src/scripts/** and used CREATE TABLE, ADD COLUMN, or ALTER COLUMN:
  Are as many columns marked NOT NULL as possible? If some columns can sometimes be null depending on other columns, are there CHECK constraints capturing those relationships, and are these also reflected using unions in the associated Kysely types?

• If you added a new signal in server/services/signalsService/signals/**:
  Did you classify every error case as a permanent error (SignalPermanentError, no retry) or a normal error (retryable)? Any case where the signal can't determine a score should be a SignalPermanentError.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}