Feature: tag-only handoff mode with deferred ARR follow-up (single cleanup owner)

[tomerh2001]

Summary

Please add a deferred / handoff mode so Decluttarr can tag problematic torrents instead of deleting them immediately, and let a separate cleanup service (e.g. qbit_manage) be the single owner of cleanup/deletion logic.

Why

In real deployments, cleanup logic is often split between tools (Decluttarr + qbit_manage + ARR settings).
That makes behavior hard to trace and can create instability/risk (especially for private trackers/HnR-sensitive torrents).

A common operations model is:

1. Decluttarr detects problematic items.
2. Decluttarr tags them for cleanup handoff.
3. External cleanup service applies the canonical retention policy and removes torrent when safe.
4. Only after actual removal is detected, Decluttarr performs ARR-side follow-up actions (blocklist/search/etc. depending on job).

This keeps a single source of truth for deletion policy while still using Decluttarr for detection + ARR orchestration.

Current gap

Today, the main actions are effectively remove/skip/obsolete_tag (tracker handling), and jobs like remove_done_seeding directly remove from the download client.
There is no explicit per-job "tag-only handoff + wait for external removal + then ARR follow-up" flow.

Proposed feature

Add a configurable mode for removal jobs, e.g.:

• action_mode: remove | skip | tag_only
• handoff_tag: "cleanup-ready" (or per-job tag)
• deferred_arr_followup: true|false
• followup_trigger: on_download_removed (download no longer present in client)
• optional timeout/fallback behavior if handoff is never completed.

Example expected behavior

For a matched problematic item with action_mode: tag_only:

1. Decluttarr adds handoff_tag to the torrent.
2. Decluttarr does not remove it from client.
3. Decluttarr tracks pending handoffs.
4. When torrent disappears from client (removed by external tool), Decluttarr runs configured ARR-side follow-up for that job.

Benefits

• Single source of truth for cleanup/deletion policy.
• Better traceability (who deleted and why).
• Lower risk of accidental premature removals.
• Cleaner integration with qbit_manage-based share-limit workflows.

Context

Related behavior/risk discussions:

• REMOVE_ORPHANS deletes valid downloads immediately upon completion (Race Condition?) #322
• detect_deletions runs even when explicitly disabled (v2.0.0) #329
• Remove done seeding not discovering items above threshold [v2.0.0] #330
• decluttarr crashes on slow server when read times out #317

If helpful, I can test this model in production and provide feedback/logs.