Bug: release-file bulk deletion can leave files behind

[e-q]

Describe the bug

The v2 API endpoint for deleting all files for a release can silently leave
files behind when the request includes another valid release-file filter.

DELETE /api/v2/downloads/release_file/delete_by_release/?release=<id> is
intended to remove every release file attached to the requested release. The
view currently reuses the normal release-file list filters for the delete
queryset, so an extra valid query parameter such as os=<id> narrows the
deletion to only that subset. The endpoint still returns 204, which makes the
request look successful even though other files for the release remain.

To Reproduce

1. Create a release with multiple release files, for example files for Windows,
   macOS, and source/Linux.

2. Send an authenticated staff request to:

   DELETE /api/v2/downloads/release_file/delete_by_release/?release=<release-id>&os=<one-os-id>
   

3. Observe that the response is 204.

4. Query the release files for that same release:

   GET /api/v2/downloads/release_file/?release=<release-id>
   

5. Files that did not match the extra os filter are still present.

Local regression-test evidence from the existing downloads API fixture:

AssertionError: 3 != 0

The request deleted only the Linux/source file and left three other files for
the same release.

Expected behavior

The delete-by-release action should delete exactly all files attached to the
requested release. Additional valid list filters should not narrow the bulk
delete action. Missing, blank, or malformed release values should return
400 Bad Request instead of reaching queryset evaluation.

Additional context

Local regression-test evidence:

FAIL: test_filter_release_file_delete_by_release
AssertionError: 3 != 0

The endpoint is used by release automation to replace release-file metadata.
Returning success after a narrowed delete can leave stale metadata rows from the
previous replacement set.

[linear-code]

PYORG-2986