Deleting an image leaks its thumbnail files on disk

DELETE /images/{id} returns a clean 204 No Content and the database row genuinely disappears -- so from the outside, deletion looks 100% successful. But the three thumbnail files it generated (thumb_small., thumb_medium., thumb_large.*) are never removed from disk. Every delete of a fully-processed image now leaks 3 files with nothing left in the database to ever reference or clean them up again. On a service whose whole job is storing images, this is a slow, silent disk-space leak that will eventually page whoever is on call when the disk fills up -- and by then there is no record left anywhere of which orphaned files belong to which (already-deleted) user upload, making cleanup a forensic exercise instead of a query.

delete_image deletes the original file from storage and the DB row, but no longer deletes the generated thumbnail files.

cd fastapi/image_service && source .venv/bin/activate pytest -q tests/test_upload.py::test_delete_removes_original_and_all_thumbnails -v

this is one of the project's own pre-existing tests -- it now fails because of this bug

app/storage.py's StorageBackend interface exists specifically so the rest of the app doesn't reach into the filesystem directly -- but that only helps if every caller that creates storage objects also remembers to clean them all up. record.thumbnails (a dict of size_name -> storage key, populated by the background pipeline once processing succeeds) is exactly the manifest needed to know what to delete; it's read correctly everywhere else (the metadata response, thumbnail download) but is no longer consulted during delete.

Look at delete_image in app/main.py. It already deletes record.original_key via storage.delete(...) -- record.thumbnails is a dict of size_name -> key populated by run_thumbnail_pipeline once processing succeeds (see how download_thumbnail reads it a few lines above, for the shape). The fix belongs right next to the existing storage.delete(record.original_key) call.