Fixes #1071
Summary
A delete with "Remove all files in the audiobook folder" removes every entry in the folder when one tracked file was renamed outside Listenarr, including another book's moved-in file. 1.3.4 refused that. This is the narrow change suggested in the issue. The gate at AudiobookFilesystemDeleteService.cs:110-122 (read, canary e1a1d12) blocks the recursive branch only when there is no live proof at all, so one live part was enough. Now the recursive branch needs every tracked path to have a live proof, or a durable ownership row. Otherwise the existing per-file branch deletes only the proven tracked files, keeps the folder, and warns.
flowchart TD
A[Delete with files] --> B{Folder target resolved?}
B -->|no| P[Per-file branch: delete only proven tracked files]
B -->|yes| C{Every tracked path has a live proof?}
C -->|yes| R[Recursive delete of the folder]
C -->|no| O{Durable ownership row?}
O -->|yes| R
O -->|no| W[Warn: tracked file missing, folder kept]
W --> P
I first gated owned folders too; 3 existing tests in LibraryController_DeleteFilesystemTests failed (measured); as I read them, they expect an owned folder with a missing tracked file to stay recursive, so owned folders are unchanged.
Testing
Five new tests (AudiobookFilesystemDeleteServiceTrackedFileGateTests) compare a sha256 manifest of the whole temp library before and after. On unmodified canary 3 of 5 fail (renamed part plus moved-in file, one part missing, all parts missing); the all-present control and the owned-folder case pass on both. All 5 pass with the change. Full unfiltered suite (measured): 3885 passed, 0 failed, 152 skipped with the change, 3880 / 0 / 152 on canary.
End to end through the API, 2 rounds each, identical (measured). The bystander book never changed; canary reproduces the wipe in S1, the control that the setup shows the bug.
| scenario | canary e1a1d12 ...
Automated Canary build