Rethink integrations: open OAuth, featured partners, no approval queue

## Summary

The current integrations model requires manual approval before a Sentry App becomes public-facing. This gate has no clear policy rationale, creates weeks of toil, and actively discourages third-party developers from building on the platform. The goal is to move to an open, self-serve integration model — matching how GitHub, Google, and other platforms operate — while maintaining a curated set of first-class featured partners in the UI.

## Current behavior

- Sentry Apps go through a manual review/approval queue before becoming publicly visible.
- The integrations listing surface mixes first-party, approved third-party, and community apps with no clear visual distinction.
- OAuth is effectively gated behind the approval process, limiting who can integrate with the platform.

## Gap

- The approval queue provides no meaningful quality signal and creates operational toil in support without a clear owner.
- Developers who don't escalate internally simply give up; the process discourages legitimate integration work.
- First-class partners (Jira, GitHub, Linear, Vercel, etc.) are visually indistinguishable from unvetted community apps, eroding trust in the listing itself.
- There is no self-serve path for anyone to build a production-grade integration without going through a moderation queue.

## Proposed direction

**Integration listing**
- Remove the integrations directory/listing as currently implemented.
- Replace with a `Featured integrations` surface that shows only explicitly promoted partners (e.g. Jira, GitHub, Linear, Vercel).
- Active/installed integrations remain visible in settings as they are today.
- An `Add integration` flow surfaces featured integrations prominently; all others are reachable via OAuth without appearing in the curated list.

**Approval / publishing**
- Remove the approval requirement from the app submission flow. Apps are usable immediately upon creation without entering a moderation queue.
- Retain the ability for Sentry to administratively delist/block an app reactively (abuse mitigation).
- The `published` / `approval status` fields can remain in the data model for operational use; the change is scoped to the submission flow defaulting to approved.

**OAuth access**
- OAuth must be available to any developer building on the platform without requiring entry into the featured list or any approval gate.
- Enforce baseline attributes at creation time (e.g. valid support contact) rather than via manual review.

**Abuse / trust**
- Add a `Report` flow for users to flag broken or abusive integrations (routes to support).
- Sentry reactively reviews flagged apps rather than proactively approving all submissions.

## Prior art

- **GitHub OAuth Apps** — any developer can register an OAuth App and publish immediately; GitHub does not curate a listing of all apps, only a marketplace of featured/paid ones.
- **Google OAuth / GCP** — apps go through a lightweight verification step only when requesting sensitive scopes; basic OAuth is self-serve.

## Open questions

- What required fields (support email, ToS URL, etc.) should be enforced at creation time as a substitute for manual review?
- Should the featured integrations list be data-driven (config/DB) or require a code change to update?
- Scope of the integration listing UI rework — tracked separately or part of this issue?

Start by reviewing the app submission flow, OAuth access path, integrations listing, and Add integration flow described in the issue. Trace how approval and published status currently affect visibility and OAuth availability. Done means self-serve app creation and OAuth, a featured-only listing, reactive reporting/blocking, and no approval queue for normal submissions.

Written by the indexing model from the issue text.