perf(storage): delete a book's file without copying it first

[GianniCarlo]

Why

Deleting a book's file did three steps inside the request:

1. copy it to deleted_<key>, a support copy that the remove-deleted-items lifecycle rule expired after 3 days;
2. delete the original;
3. answer.

With multipart uploads, books of several GB are now common. For a 3 GB book the server-side copy held the delete for about a minute, and the apps' serial sync queue waited behind it, so a delete looked stuck.

Seen in the iOS device pass: a 3.02 GiB book's delete took about a minute, and its support copy was written as it finished. The copy hasn't been needed for support in a long while.

What

• S3Service.deleteFile sends one DeleteObject, with no copy first.
• The 5 GiB fallback (feat(library): upload books to S3 in parts, confirmed by the server #50), which skipped the copy for books too large for a single CopyObject, goes with it, along with its HEAD size check.
• Folders' placeholder objects are deleted the same way.

After this deploys, the remove-deleted-items lifecycle rule has nothing to act on once the existing deleted_ copies expire, within 3 days. It can then be removed from the bucket; it's harmless if left.

Tests

• deleteFile sends exactly one DeleteObject and copies nothing.
• A delete that S3 refuses answers null.
• The tests built around the support copy are removed.
• 459 tests on Postgres 17.
• Device pass, with the local API on this branch against production: a 326 MB book and a 78 MB book deleted from the app cleared at once. Their rows went inactive, the objects are gone, and no deleted_ copies were made.

[github-actions]

✅ Claude PR Review — PASS

Makes S3Service.deleteFile send a single DeleteObjectCommand and drops the deleted_ support copy, the >5 GiB HEAD fallback, and their tests. No routes, middleware, or authorization logic change. Callers (LibraryService book and folder deletes, MultipartUploadService) are unchanged and still pass keys they build themselves, so key scoping is unaffected. The error path still logs with a stripped key and returns null. No IAP or passkey code is involved. Worth knowing: without the support copy, deleted books can't be recovered unless the bucket has versioning, which the PR says is intended.

Findings: no findings

Converged: nothing new this round, and no earlier finding is open.

_{Model claude-opus-5-5 · run log · 0 new · 0 carried over · 0 resolved · advisory (a human should still review). Findings are de-duplicated across pushes; an earlier finding closes only when the verification pass judges it against the current code — fixed, no longer applicable, accepted by a maintainer, or a duplicate of a finding reported on this push.}