Cross-project source map resolution for microfrontends

### Problem Statement

I am using Sentry in a **self-hosted environment** with a microfrontend architecture where applications are independently built, deployed, and composed at runtime (e.g. module federation or dynamic CDN-based loading).

Each microfrontend produces its own JavaScript bundles with hidden source maps containing valid `debugId` values.

At runtime, Sentry events frequently contain stack traces that span multiple microfrontends. For example, an error originating in one microfrontend may include frames from shared or dynamically loaded code belonging to another microfrontend.

The issue is that source map resolution in self-hosted Sentry is scoped to the project/release that received the event. Even though `debugId` correctly identifies the originating bundle, Sentry only resolves source maps within the same project context.

This results in partially or fully minified stack traces when frames originate from other microfrontends, even when the correct source maps exist in other projects within the same self-hosted Sentry instance.

---

### Core limitation

There is currently no mechanism in self-hosted Sentry to resolve source maps across projects using `debugId`, even when:

- The `debugId` uniquely identifies the correct bundle
- The source map exists in another project in the same self-hosted instance
- The runtime composition of microfrontends is dynamic and not known at build time

---

### Why this is a problem

In microfrontend architectures:

- Bundles are independently deployed and versioned
- Runtime composition is dynamic and not centrally known
- A single bundle may execute in multiple unrelated application contexts
- New consuming applications may appear after deployment

Because of this, it is not possible to predefine or maintain a complete mapping of which Sentry projects should receive a given microfrontend’s source maps (to use option from #85226)

As a result, strict project-scoped source map resolution does not scale for self-hosted microfrontend environments.

### Solution Brainstorm

Introduce support in self-hosted Sentry for **cross-project or instance-wide source map resolution based on `debugId`**.

### 1. Instance-wide `debugId` lookup
Allow Sentry to resolve source maps across all projects in the self-hosted instance using `debugId`, instead of limiting resolution to the event’s project.

### 2. Cross-project artifact resolution scope
Introduce a configurable scope that allows source map lookup across a defined set of projects within the same self-hosted installation.

### 3. Global source map registry (instance-level)
Treat source maps as instance-level artifacts rather than project-scoped assets, enabling reuse across microfrontends.

### 4. Explicit resolution mode configuration
Provide a setting such as:
- project-only (current behavior)
- instance-wide lookup
- configured project list

---

## Why this matters

This limitation becomes especially important in self-hosted environments because:

- Organizations often host multiple microfrontends under a single Sentry instance
- Cross-team ownership boundaries are stricter
- There is no external SaaS artifact coordination layer
- Microfrontend adoption increases runtime composition complexity over time

Without cross-project resolution, debugging distributed frontend systems becomes fragmented and incomplete.

### Product Area

Issues - Source Maps

The issue names no files, tests, or entry points. Start by tracing the existing project-scoped source-map resolution and compare it with the proposed debugId lookup modes; done means an agreed, implemented resolution scope that handles frames from multiple projects in a self-hosted instance.

Written by the indexing model from the issue text.