fix(coding-conventions): Ensure stable component identity for InlineEventAttachment

[sentry]

This PR addresses a static-component-definitions violation reported by the React Compiler in static/app/views/issueDetails/groupEventAttachments/inlineEventAttachment.tsx.

Problem:
The InlineEventAttachment component was dynamically determining the AttachmentComponent to render by calling getInlineAttachmentRenderer(attachment) inside its render function. The React Compiler interprets this pattern as creating a new component identity on every render, which can lead to state resets and prevents compiler optimizations.

Solution:
To resolve this, the dynamic component selection logic has been encapsulated within a new, static functional component called AttachmentViewer. InlineEventAttachment now renders this AttachmentViewer directly. The AttachmentViewer component then uses conditional rendering (if statements) to return the appropriate static viewer component (e.g., ImageViewer, VideoViewer, JsonViewer).

This ensures that the component type used in JSX (<AttachmentViewer />) is always a stable, statically defined reference, satisfying the React Compiler's StaticComponents rule and preventing the static-component-definitions violation.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes CODING-CONVENTIONS-36F

_{Comment @sentry <feedback> on this PR to have Autofix iterate on the changes.}

[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 a5c380f. Configure here.}

[cursor]

Duplicated attachment viewer selection

Medium Severity

AttachmentViewer reimplements the mime-type selection already owned by getInlineAttachmentRenderer, including local copies of logFileMimeTypes and jsonMimeTypes. The copy also omits the nonPreviewableExtensions guard, so the gate and renderer can drift and pick different viewers later.

 

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

[sentry]

Bug: The logFileMimeTypes and jsonMimeTypes arrays are duplicated, creating a risk of them becoming out of sync with the source, which could lead to rendering failures.
_{Severity: LOW}

Suggested Fix

To prevent future divergence, export the logFileMimeTypes and jsonMimeTypes arrays from previewAttachmentTypes.tsx. Then, import and use these arrays directly in inlineEventAttachment.tsx instead of using locally-defined duplicates.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
static/app/views/issueDetails/groupEventAttachments/inlineEventAttachment.tsx#L31-L43

Potential issue: The `logFileMimeTypes` and `jsonMimeTypes` arrays are locally
re-defined in `inlineEventAttachment.tsx`, duplicating the same un-exported arrays from
`previewAttachmentTypes.tsx`. While currently synchronized, this creates a
maintainability issue. If the source arrays in `previewAttachmentTypes.tsx` are updated
in the future to support new MIME types, the duplicated arrays in this component will
not be updated automatically. This divergence would cause the attachment viewer to fail
to render an attachment (returning `null`) even after the initial guard check passes,
because the local MIME type list would be stale.

_{Did we get this right? 👍 / 👎 to inform future reviews.}