feat(api): Union response annotations with plugin narrowing + relaxed linter

[azulus]

Three pieces of infrastructure that together enable typing endpoints with
mixed return shapes (success TypedDict + inline error bodies) without
business-logic changes.

Plugin narrowing across union arms

The mypy plugin gains a sibling hook to the body-Any check. When
Response(<literal>, ...) is constructed inside a function returning a
union of Response[...] arms, the plugin narrows the literal to one
arm structurally:

Non-empty dict literal       → TypedDict-coercion check per arm's T
Empty dict literal `{}`      → matches dict[K,V] or no-required-keys TypedDict
Empty list literal `[]`      → matches list[T] arms

Exactly one match → returns Response[that_T]. Zero (drift) or multiple
(ambiguous) → falls back to default. The plugin is name-agnostic —
no hardcoded TypedDict names. It does for unions what mypy already does
in single-target Response[T] contexts, which mypy intentionally
refuses to extend to unions (bidirectional TypedDict-from-literal
inference is single-target only by design).

Linter relaxation: set-subset, not set-equality

The structural linter (#116496) now requires the decorator's typed-T
set to be a subset of the annotation's typed-T set, not equal.

Before (set-equality):
─────────────────────
Decorator: {200: inline_sentry_response_serializer("X", T)}
Annotation: Response[T] | Response[ErrorT]
              → mismatch (annotation declares more)

After (set-subset):
───────────────────
Same input → linter passes. {T} ⊆ {T, ErrorT}.

This lets endpoints enrich their internal annotations (e.g. local error
TypedDicts) without forcing decorator migrations that would change the
OpenAPI document. Drift in the other direction (decorator declares T that
annotation omits) is still caught.

src/sentry/apidocs/response_types.py as a shared-shapes module

A small module that holds TypedDict shapes recurring across endpoints.
Initial contents: DetailResponse (DRF's standard {"detail": str}
shape). The module is not authoritative — endpoints whose error
shapes don't match anything here are expected to declare local
TypedDicts in their own files. The linter is name-agnostic, treating
shared and local TypedDicts identically.

Migration coverage in this PR: 9 of 25 candidate endpoints

Migrated under the new infrastructure:

src/sentry/api/endpoints/debug_files.py
src/sentry/issues/endpoints/organization_eventid.py
src/sentry/issues/endpoints/project_event_details.py
src/sentry/integrations/api/endpoints/organization_config_integrations.py
src/sentry/integrations/api/endpoints/organization_integrations_index.py
src/sentry/preprod/api/endpoints/public/organization_preprod_size_analysis.py
src/sentry/preprod/api/endpoints/public/organization_preprod_artifact_install_details.py
src/sentry/issues/endpoints/group_events.py            (plugin G1 — empty list)
src/sentry/replays/endpoints/organization_replay_count.py (plugin G1 — empty dict)

Each migrated endpoint's diff is exactly two things: add a DetailResponse
import, and change the return annotation from Response to a union.

The other 16 candidates stay unmigrated

They have body sources that are typed Any at the runtime API surface
(serializer.errors returns DRF ReturnDict[Any, Any], pydantic
resp.dict() returns dict[str, Any], untyped helper functions), or
inline bodies with custom nested shapes that don't match shared
TypedDicts. Migrating them requires improving the source — typing DRF
stubs better, typing pydantic dict() returns, etc. — not changing how
the endpoints work. They stay bare--> Response until the source
typing catches up.

No runtime changes anywhere. No cast() calls. No # type: ignore
comments. No return → raise conversions. Plugin and linter operate
purely at type-check time.

Verification

• Full-tree mypy (8038 files): clean in src/ and tests/
• prek: clean
• Structural linter: clean
• make build-api-docs: byte-identical to master
• Plugin tests: 39/39 pass (29 existing + 7 union-narrowing + 3 empty-literal/name-agnostic)
• Linter tests: 19/19 pass (16 existing + 3 subset-semantic scenarios)