Extend similar-issue detection across projects, not only within a single project

Problem Statement

Similarity detection is scoped to a single project. Cross-Project Issues lets you
view issues from several projects in one stream, and Similar Issues will find
related issues inside one project, but nothing detects that an issue in project A
and an issue in project B are the same defect.

Organizations that share code across products hit this constantly: a shared engine,
an internal SDK, a common platform or publishing layer. When a defect lands in that
shared code it surfaces as separate issues in separate projects, each investigated
independently by a different team, often reaching the same conclusion days apart.

The inverse case is worse. A shared-layer regression looks like a small local
problem in each project, so its true blast radius is never visible to anyone, and
prioritisation is wrong by construction: an issue affecting five projects gets
triaged as five separate small issues.

Project boundaries are organisational. Defects follow code, and shared code crosses
those boundaries. There is currently no way to ask "is anyone else seeing this
crash", which is the first question anyone asks during a shared-layer incident.

Solution Brainstorm

• Extend similarity detection to operate across projects within an organization,
  subject to the viewer's project permissions.
• A "seen in other projects" indicator on the issue page, with counts and links.
• Support correlating by shared stack frame or shared module across projects, so a
  common-layer regression can be recognised as one thing even when the surrounding
  frames differ.
• Surface it in the cross-project issue stream, where users are already looking
  across the boundary.

Related: #101821

Product Area

Issues

Requested by Saad Khan.

--

View Junior Session [Sentry]

Start by reading related issue #101821 and tracing the existing Similar Issues and Cross-Project Issues entry points. Define how cross-project permissions, shared stack frames or modules, issue-page indicators, and cross-project stream results should work; done means a scoped design and implementation plan with clear acceptance criteria.