fix(attachments): infer MIME type from filename when stored as octet-stream

[sentry-junior]

Summary

normalize_content_type in src/sentry/models/eventattachment.py treats application/octet-stream as a valid explicit content type, so filename-based MIME inference via mimetypes.guess_type is never reached. This causes the attachment download endpoint to serve images (e.g., screenshot.png) as application/octet-stream, breaking consumers that rely on the Content-Type header to process the file.

Change

Treat application/octet-stream as equivalent to None in normalize_content_type, allowing the existing mimetypes.guess_type(name) fallback to infer the correct MIME type from the filename.

Files changed

• src/sentry/models/eventattachment.py — 2-line fix in normalize_content_type
• tests/sentry/models/test_eventattachment.py — 6 new unit tests covering the function

Fixes #115976

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5b51516. Configure here.}

[github-actions]

Backend Test Failures

Failures on ed7cc27 in this run:

tests/symbolicator/test_minidump_full.py::SymbolicatorMinidumpIntegrationTest::test_full_minidump_invalid_extra — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/symbolicator/test_minidump_full.py:139: in test_full_minidump_invalid_extra
    event = self.post_and_retrieve_minidump(
src/sentry/testutils/relay.py:127: in post_and_retrieve_minidump
    assert resp.ok
E   assert False
E    +  where False = <Response [503]>.ok