Allow searching and filtering issues by which modules were loaded at the time of the crash

Problem Statement

Native crash reports include the full list of loaded modules: DLLs, drivers,
injected overlays, graphics runtimes. This data is captured and displayed on the
event, but it is not searchable. There is no way to ask "show me every crash where
overlay X was loaded" or "every crash on graphics driver version Y".

For desktop and console applications, third-party injected modules are one of the
largest single causes of crashes that look like application bugs but are not.
Overlays, capture tools, anti-cheat layers, and out-of-date graphics drivers all
present as crashes inside the application's own stack.

Because the module list cannot be filtered on:

• Every one of these is triaged by hand.
• Teams cannot quantify how much of their crash volume is attributable to a given
  third-party module, so they cannot prioritise it and cannot prove to the third
  party that its module is the cause.
• The only workaround is exporting events and grepping the module list offline.

The data already exists on every native event. It is simply not indexed.

Solution Brainstorm

• Index the loaded-modules list as a searchable, multi-value attribute, including
  module name and version.
• Support it in issue search, in Explore, and in dashboard group-bys, so a team can
  chart crash volume by loaded module over time.
• Surface a loaded-module breakdown on the issue page, in the same spirit as the
  existing tag distribution, so the correlation is visible without a query.

Product Area

Issues

Requested by Saad Khan.

--

View Junior Session [Sentry]

No files, tests, or entry points are named. Start by tracing where native-event loaded modules are stored and how issue search indexes multi-value attributes; then review Explore, dashboard group-bys, and issue-page breakdowns. Done means module name and version can be searched, filtered, grouped, and displayed as described.