Report exact transfer files to Transmission clients - #52

The bindery side (#903 / #933) lines up.

Two changes should be separate from the manifest feature because they're independent bug fixes:

• The FileID == 0 guards (manager.go:174, transfers.go:430). Put.io uses 0 for the root folder, so the old code could hand the account root to DeleteFile. That's a serious bug on its own, and TestCleanupNeverDeletesPutioRoot is exactly the right test for it.
• Switching to context.WithCancelCause so a stall-cancelled download is classified transient instead of as a shutdown cancellation.

Can you pull those into their own commits or a separate PR? I'd merge them ahead of the manifest work.

On the rest:

1. handleTorrentRemove now only calls RemoveCategory/RemoveTransfer when DeleteTransfer succeeded (torrent.go:553). I understand why, but a transfer whose remote deletion keeps failing now keeps its category and manifest for the process lifetime. torrent-remove was the thing that bounded tracking growth. Can we cap this — retry N times, or drop local tracking after a deadline and log it?

2. localTorrentFiles sets bytesCompleted = length for every file once percentDone >= 1. That's fine as a simplification, but the field promises per-file progress. Add a comment saying it's whole-transfer granularity, or source it from the per-file state we already track.

3. The progress change (no-context COMPLETED/SEEDING now 0.5 / downloading instead of 1.0 / seeding) is correct — put.io done is not plundrio done — but it changes what every existing *arr sees on restart. Please call it out in the PR body as a behaviour change so it lands in the release notes.

4. .plundrio-files is a new reserved directory in the download root. It's excluded from deleteLocalData and from manifest names, but it'll be visible to anything else that walks TargetDir. See my note on feat: reconcile unmanaged downloads #51 — the two PRs collide there.

Cross-PR note, since all four of these are open at once.

All four touch internal/server/torrent.go in the same region, and #49 and #50 conflict textually. Proposed order:

1. Report exact transfer files to Transmission clients #52 (fixes the root-folder delete bug and the premature-completion state)
2. fix(rpc): mark completed transfers removable #49 (only safe after Report exact transfer files to Transmission clients #52)
3. feat: report stalled Put.io transfers #50 (rebase; keep the int error field, Report exact transfer files to Transmission clients #52 still emits a bool)
4. feat: reconcile unmanaged downloads #51 (pending the scope discussion)

Separately, CI only runs go build and go test. Given how much of this repo is concurrency, -race should be in the pipeline before we take any of these. I've run go vet and go test -race against all four locally and they're clean.

Thanks for both the detailed review and the cross-PR sequencing note. I've updated the original PR description, including the upgrade/restart behavior for release notes, and incorporated your suggestions.

• Root-deletion protection plus race CI are separate in fix: prevent Put.io root deletion and enable race CI #53; stalled cancellation/retry classification is separate in fix: preserve stalled download cancellation for retries #54. Both can land first.
• Remote removal is bounded to three attempts per request. Durable removal intent preserves ownership evidence while active in-memory tracking is released; regression coverage includes blocked queues, storage, and restart behavior.
• Whole-transfer bytesCompleted granularity is documented, and feat: reconcile unmanaged downloads #51 excludes .plundrio-files/ and protects pending-removal payloads.
• Remote completion without proven local completion no longer reports complete. Unverifiable legacy records enter persistent warning-only review holds, with explicit record-only retirement after retained-copy verification.

The history is now two feature commits after the shared safety prerequisites, with the exact previously published source tree preserved. The new boundary passes go test -race ./.... The stack retains #53/#54 → #52 → #49 → #50 → #51, including #50's separate integer-error fix; #51 remains subject to scope agreement.

Thanks for the extremely thorough writeup and testing notes on this one — the durability/generation-reservation discipline throughout removal.go/review.go/transfers.go is great, and it all builds, vets, and passes go test -race ./... cleanly for me on a rebase onto current main.

One thing I want to confirm intent on before merging.

handleTorrentRemove used to process each ID in a batch independently — a failure (missing transfer, failed DeleteTransfer) was logged and the loop moved on to the next ID. With this PR, a PrepareRemoval failure (e.g. a completed transfer that hasn't hit its first monitor poll yet) or an exhausted 3-attempt DeleteTransfer now returns an error immediately, which aborts the RPC call for the rest of the batch — any IDs after the failing one in the same torrent-remove request are never attempted.

Is that an intentional fail-fast tradeoff, or should a per-ID failure still let the rest of the batch proceed (matching the old best-effort behavior, just with the new safety bookkeeping)? Sonarr/Radarr can send multi-ID torrent-remove calls, so this changes what a bulk-delete-from-queue actually does on partial failure. No test currently covers a multi-ID batch either way, so happy to help pin down whichever behavior you intend.

Everything else looks solid to me — nothing further blocking on my end once this is settled.

Thanks for catching this. The fail-fast behavior was unintended; ordinary multi-ID torrent-remove should continue attempting later IDs after a per-ID failure.

Commit 6ae264a restores that behavior. Preparation failures and exhausted three-attempt remote deletions are collected, processing continues through the batch, and the combined errors are returned afterward. Failed IDs retain local payload and ownership evidence; successful later IDs complete cleanup. The explicit reviewed-retirement guard remains separate.

The added regression covers preparation failure, exhausted remote deletion, mixed failures, and a successful control, including absent selectors and retained manifests/categories. The PR description records the before/after regression and local race-test, vet, and build results.

The updated head also passes hosted CI. This follow-up has not been deployed or exercised against live Put.io/Arr services.

Could you take another look at the batch-removal fix? With #53 and #54 merged, this remains the next PR in the agreed sequence.

The batch-removal fix looks right — I reverted torrent.go to the pre-fix version locally and confirmed TestTorrentRemoveContinuesBatchAfterFailure genuinely fails 3/4 subtests without it, so this isn't a vacuous test. errors.Join + continue is the correct shape, and it matches the old best-effort semantics exactly. go test -race ./..., vet, and build all clean.

LGTM, merging.