Write: gate launch on email verification in the post-publish overlay

[allilevine]

Fixes READ-580

Proposed changes

Follow-up to #49935. That PR added the post-publish overlay and a placeholder "confirm your email to launch" step whose Resend and re-check were deferred (they needed a transport that works on a Simple site's front end). This PR builds them.

• Two logged-in-only admin-ajax handlers in the Write feature, each a thin wrapper around the wpcom Email_Verification class, guarded by class_exists so they fail safe off-wpcom:
  • wpcom_write_resend_verification_email → Email_Verification::resend_verification_email()
  • wpcom_write_check_email_verification → { verified: ! Email_Verification::is_email_unverified() }
• The overlay now localizes an ajaxUrl + nonce and the new step strings.
• showVerifyStep() gains a Resend verification email button, and its confirm button now re-checks verification before proceeding: a verified author is sent to the launch flow, while a still-unverified one gets an inline "not confirmed yet" message and can't slip past. The wpcom back-end 403 gate remains the authoritative enforcement (defense-in-depth).
• admin-ajax is the transport because a wpcom Simple site serves no REST API at its own hostname; the blocked state stays computed server-side and rendered into the page.

All complexity stays in Write On-owned code — the shared Calypso /start/launch-site flow is untouched (the reason the Calypso approach in Automattic/wp-calypso#112239 was closed).

Related product discussion/links

• READ-580

Does this pull request change what data or activity we track or use?

Adds front-end Tracks events for the verify step: wpcom_write_post_publish_checklist_resend_click, _verify_recheck, _verify_confirmed, and _verify_still_blocked. These are UI-interaction events only; no new personal data is collected.

Testing instructions

This gating only engages on a wpcom Simple site created via the Write On flow (site_creation_flow = 'write-on') whose owner has an unverified email, since it depends on the wpcom-only Email_Verification class. On such a site:

• Publish a post in the Write editor while the site is Coming Soon; on the published post the overlay appears.
• Click Launch your site → the step swaps to "Confirm your email to launch" with I've confirmed — launch and Resend verification email.
• Click Resend verification email → a new verification email is sent and an inline confirmation appears.
• Before verifying, click I've confirmed — launch → it re-checks and shows the "not confirmed yet" message (no launch).
• Click the verification link out-of-band, then I've confirmed — launch → proceeds to the launch flow.

Local verification (plain Jetpack dev env, where Email_Verification is absent) confirmed: the overlay renders with the new localized config (ajaxUrl, nonce, all step strings); both admin-ajax actions are registered and reachable (valid nonce → the class_exists guard's unavailable response; bad nonce → -1/403); and all four showVerifyStep() branches behave correctly when fetch is stubbed to simulate the wpcom responses (resend-sent message, still-unverified message with buttons re-enabled, and navigate-to-launch on verified). New PHPUnit coverage exercises both handlers via a mocked Email_Verification.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (WordPress.com Site Helper), and enable the add/write-on-email-verification-launch-gate branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/write-on-email-verification-launch-gate

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/jetpack-mu-wpcom/src/features/write/post-publish-checklist.js	0/300 (0.00%)	0.00%	83 💔
projects/packages/jetpack-mu-wpcom/src/features/write/email-verification.php	11/18 (61.11%)	3.97%	4 💔
projects/packages/jetpack-mu-wpcom/src/features/write/post-publish-checklist.php	80/84 (95.24%)	0.79%	0 💚

Full summary · PHP report · JS report

_{Coverage check overridden by I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage. .}