Write On: handle email_unverified launch error in the launch-site flow

[allilevine]

Part of READ-569

Proposed Changes

• Handle the email_unverified launch error in the /start/launch-site flow's launch step (client/signup/steps/launch-site). When the launch endpoint returns 403 email_unverified, the step now renders an inline "Verify your email to launch" panel with Resend verification email and Try again actions, instead of leaving the user on a blank, silently-failed step.
• Reworked the step to submit the launch once (guarded on step status) and only render for the email-verification case — the flow's own processing screen covers the pending state and success still advances via the flow controller. The guard prevents a resubmit loop caused by the processing screen unmounting/remounting the step.
• Reuses the existing verifyEmail() action for the resend; uses @wordpress/components primitives and design-system color tokens.
• Added unit tests covering: single submit on mount, no resubmit while in progress, renders nothing while pending / on success / on non-email failure, the panel on email_unverified, and the resend + retry actions.

Why are these changes being made?

The wpcom launch endpoints now return 403 email_unverified for Write On sites (site_creation_flow = 'write-on') whose owner has an unverified email — companion back-end change 225485-ghe-Automattic/wpcom. Previously the launch step navigated away on mount and swallowed any error, so an unverified author who reached launch (e.g. from the post-publish checklist's Launch CTA) got no feedback and a site that silently stayed private. This gives them an honest, actionable next step. The email_unverified code is only ever returned for Write On sites, so the handling is inherently scoped to that flow and every other launch path is unchanged.

Testing Instructions

1. With a logged-in account whose email is unverified, on a Write On site (site_creation_flow = 'write-on', Coming Soon), go through /start/launch-site → domains-launch → plans-launch (Free) → the launch step.
2. The launch API returns 403 email_unverified; confirm the "Verify your email to launch" panel appears (heading + description + Resend verification email + Try again).
3. Click Resend verification email → confirm the "confirmation email sent" global notice.
4. Click Try again while still unverified → briefly shows the launch screen, then returns to the panel (no loop).
5. With a verified email, the same path launches normally (no panel).
6. On a non-Write On site, launch is not gated (panel never appears).

Unit tests: yarn test-client client/signup/steps/launch-site/test/index.jsx

Known pre-existing behavior (not introduced here): refreshing the browser directly on the transient launch step renders a blank page — the signup app short-circuits to null for a non-first step with empty progress (client/signup/main.jsx), above this component. The normal user path does not hit this.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• For UI changes, have you tested the affected components in dark mode?
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

🤖 Generated with Claude Code

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-186155

Jetpack Cloud Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-186155&env=jetpack

Automattic for Agencies Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-186155&env=a8c-for-agencies

Dashboard Live (dotcom) (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-186155&env=dashboard

Dashboard Live (A4A) (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-186155&env=dashboard-a4a

[allilevine]

Closing this in favor of handling the email-verification prompt in the Write On-owned surface instead of the shared launch flow.

Rationale: the /start/launch-site flow is shared by every free Coming Soon launch (very high traffic), and reworking its terminal launch step to surface a Write On-only error added more navigation/render complexity to that shared flow than a limited experiment warrants. The launch step is terminal with only a success destination, so there's no clean place to surface a failure there — a signal the error doesn't belong in the shared flow.

The back-end gate (225485-ghe-Automattic/wpcom) is correct and stays: it blocks launch for unverified Write On sites regardless of the client, so the site genuinely stays private. That makes the 403 pure defense-in-depth.

New plan: surface the "verify your email to launch" UX in the Write On overlay (which already computes the write-on + unverified blocked state server-side), stopping unverified users before they reach the shared launch flow — plus a verification re-check. This keeps all experiment complexity in experiment-owned code and leaves the shared Calypso launch flow untouched.

Tracked in READ-569.