chore(scm-first-messaging-integration): Fetching providers list and exposing connection status

[Abdkhan14]

Blocked by: #121964

Problem

The new inline messaging step needs to render one row per curated provider (Slack, Discord, MS Teams), each showing whether that provider is installable, already connected, or connected-but-ineligible. Nothing in the codebase produces that shape. SetupMessagingIntegrationButton runs nearly the same two queries but reduces them to a flat, unkeyed providers[] and a single all-or-nothing boolean ("is nothing active?"), with the logic buried inside a component alongside modal and feature-gate rendering. useScmProviders follows the same pattern but for a different domain — source-code providers filtered by isScmProvider, returning raw Integration[] with no messaging keys or issue-alert eligibility. Neither gives the rows a per-provider, status-carrying view model to bind to.

Fix

Add useScmMessagingProviders, a purpose-built data hook that joins the two endpoints — /integrations/?integrationType=messaging (installed integrations) and a useQueries fan-out over /config/integrations/?provider_key=… (provider metadata for each curated key) — and transforms them into one ScmMessagingProviderViewModel per provider. It preserves the index→key association so row order always matches SCM_MESSAGING_PROVIDER_KEYS, ignores inactive integrations (treating them as uninstalled via the shared isIntegrationActive), and computes a status per row: installable (no active integration), connected (active and eligible), or permission-limited (tenant-type MS Teams, which can't receive issue alerts). It also exposes refetchIntegrations() so row components can refresh state after a successful install. Covered by 7 tests spanning every status transition, inactive-ignored, error state, and ordering.

[github-actions]

📊 Type Coverage Diff

Metric	Before	After	Delta
Coverage	94.29%	94.29%	±0%
Typed	133,855	133,874	🟢 +19
Untyped	8,113	8,114	🔴 +1

🔍 1 new type safety issue introduced

Type assertions (as) (1 new)

File	Line	Detail
static/app/components/onboarding/scm/useScmMessagingProviders.ts	92	as Partial<Record<ScmMessagingProviderKey, IntegrationProvider>> — Object.fromEntries( results.map((r, i) => [SCM_MESSAGING_PROVIDER_KEYS[i], r.da…

This is informational only and does not block the PR.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d756fbb. Configure here.}

[jaydgoss]

could these as anys be {...OrganizationIntegrationsFixture().provider, key: 'msteams'} instead? the slack one is already the fixture default so it can just go away

[Abdkhan14]

Yup valid, I pushed the change for this, remove the anys

[jaydgoss]

medium: the experiment supports one selected destination, but this currently takes only the first active integration for each provider. an org with multiple Slack workspaces will have no way to select another workspace in the downstream single-select. could the view model preserve all active integrations for this provider while still allowing only one selected destination?