feat(onboarding): Add SCM messaging treatment route

[jaydgoss]

TLDR

Adds the treatment-only fifth SCM onboarding step between platform/features and SDK setup, preserving the four-step control flow. The messaging destination slot persists in the onboarding session and survives refresh, Back, and repository/platform changes. Treatment entry creates no project.

Details

Stacked on #121022, which makes onboarding session exits explicit and is the prerequisite for persisting anything that must outlive a platform change; that in turn sat on #120981, which registered the distinct onboarding-scm-messaging-experiment key and has merged. The FlagPole config is getsentry/sentry-options-automator#9012, deliberately scoped to a single throwaway developer alias.

This layer establishes only the route and the session contract. It has no forward navigation on completion by design: VDY-141 owns shared project and alert-rule creation on final Continue or Set up later, VDY-143 owns inline destination configuration, and VDY-146 owns exposure and interaction analytics. A placeholder onComplete here would be deleted by VDY-141 and would strand users on a blank setup-docs, which renders off recentCreatedProject and bails when absent. Because treatment cannot complete yet, the flag must not widen beyond that alias until VDY-141 lands.

Revalidation of a restored destination is stacked separately in #121187. Nothing in this PR can write a selected or skipped destination — VDY-143 adds the picker and VDY-141 adds Set up later — so that logic has no reachable consumer yet and is better reviewed on its own.

The onboarding host consumes the nested assignment without reporting exposure and selects separate control and treatment step descriptors from entry, sharing the Welcome and repository steps. ScmPlatformFeatures keeps the existing control creation boundary but only stages platform and feature choices for treatment before advancing to scm-messaging; deferProjectCreation also drops the teams/projects store gate, which only the auto-create path needs. Global Skip resets the onboarding session and exits without creating a project. Stepper gained role="progressbar" with aria-valuemax, making the four- versus five-step split both accessible and assertable.

OnboardingContextProvider persists a typed unconfigured, skipped, or completed messaging destination in the existing session value, as a discriminated union so a partially-filled destination is unrepresentable. Because #121022 made field setters local, SCM repository, platform, refresh, and Back paths all preserve organization-scoped messaging state.

Two session-exit behavior changes live here rather than in #121022, because the new step is what requires them. OnboardingSkipButton now calls resetOnboarding, which it previously did not do at all: treatment ends on scm-messaging, the last step before project creation, so skipping there must not leave a half-staged session for the next /onboarding visit to resume from. useWelcomeAnalyticsEffect stops resetting on the SCM path and clears only repo-derived state via clearDerivedState, because messagingSetup is organization-scoped and must survive a return to Welcome. Neither exit affects anything downstream of onboarding: the onboarding sessionStorage key has exactly one reader, OnboardingContextProvider, mounted only under the /onboarding/:step/ route, and the post-onboarding quick-start checklist is server-backed via /organizations/{org}/onboarding-tasks/.

Coverage exercises the four- versus five-step split, deferred creation, session remount and Back behavior, and global Skip.

Refs VDY-140

[linear-code]

VDY-140

[sentry]

Sentry Snapshot Testing

Name	Added	Removed	Changed	Renamed	Unchanged	Skipped	Status
sentry-frontend sentry-frontend	-	-	-	-	-	-	✅ 451 uploaded

No base snapshots found to compare against. Make sure snapshots are uploaded from your main branch.

⚙️ sentry-frontend Snapshot Settings

[sentry]

Bug: The isInvalidMessagingStep check can redirect legacy users to scm-platform-features, a step not in their flow, causing a double redirect before landing on the correct fallback page.
_{Severity: LOW}

Suggested Fix

Update the redirect logic to ensure the fallback step exists in the current user's onboardingSteps array. One option is to gate the isInvalidMessagingStep check on hasScmMessaging. Alternatively, choose a safer fallback step, such as the first step in the current flow, which is guaranteed to exist.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: static/app/views/onboarding/onboarding.tsx#L460-L464

Potential issue: For users in the legacy onboarding flow, navigating to the
`scm-messaging` step without a `selectedPlatform` in context triggers the
`isInvalidMessagingStep` condition. This incorrectly redirects them to the
`scm-platform-features` step, which does not exist in the `legacyOnboardingSteps` array.
The application then performs a second redirect to the default `welcome` step. This
double-redirect occurs because the fallback logic for an invalid messaging step does not
account for different user onboarding flows and assumes the `scm-platform-features` step
is always available.

[jaydgoss]

Fixed in 882961a. The SCM-platform fallback now applies only when the messaging treatment is active, so inactive messaging routes use the current flow’s normal first-step fallback. Added a control-flow regression test.