Deleted files leave source uploads and attachment blobs in storage

When a file is deleted, the database rows are removed and the logs report success, but the underlying objects stay in Cloud Storage indefinitely.

Evidence (production, 16 July deletion, still present 20 July)

• Logs show the full happy path: Attachments cleaned up and unreferenced blobs queued for reap, Starting async PDF cleanup, File deleted successfully.
• Despite this, thousands of attachment blobs remain under the project's attachments/ prefix in the uploads bucket.
• The original uploaded source files also remain under the user's uploads/ prefix — they do not appear to be removed by the delete path at all.
• Four days later none of these objects have been reaped.

Why it matters

This is a retention and data-protection gap, not just wasted storage. A customer who deletes their content — often the whole point of a redaction workflow — still has the original documents and attachments held on our infrastructure, including personal data belonging to third parties. Deletion must actually delete.

Suggested next step

Verify the reap queue is receiving rows and is actually being drained, confirm the delete path removes the source upload as well as attachments, and backfill a cleanup for objects already orphaned by past deletions.