Restrict Site Transfer Input to Email Addresses

[okmttdhr]

Related to #87001, D137375-code, D167877-code

Proposed Changes

This PR modifies the site transfer functionality to restrict the transfer input field to only accept email addresses, disallowing usernames.

• This also resolves p1733387208740199/1733361636.672369-slack-CRWCHQGUB indirectly.
• Site members can still be searched by username (the value being sent will be the email). I believe this approach provides good enough usability.
• Users can transfer Jetpack-connected sites via /settings/manage-connection/:siteSlug. This process is already safe because the recipient is selected from a list of site administrators, eliminating the user-input field.

UI changes;

before	after

Why are these changes being made?

This change addresses an issue where users might mistakenly enter a username instead of an email address, causing transfer emails to be sent to unintended recipients. https://github.com/Automattic/dotcom-forge/issues/8540

Testing Instructions

• Patch D167877-code to your sandbox
• Go to /settings/start-site-transfer/<site>?flags=-untangling/hosting-menu

Transfer to a non-member of your site;

• Input a username
• Click "Continue"
• Observe the error: "The specified email is not a valid email address."
• Input an email
• Click "Continue"
• Observe the UI is redirected to "Confirm site transfer"
• Accept statements and click "Start transfer"
• Observe the email is sent to the user

Transfer to a member of your site;

• Input a username
• Observe the user is displayed
• Click "Continue"
• Observe the error: "The specified email is not a valid email address."
• Click "Transfer ownership"
• Observe the UI is redirected to "Confirm site transfer"
• Accept statements and click "Start transfer"
• Observe the email is sent to the user

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?
• 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)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-50de310139d888c952206fd5e3fc133605526de9

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-50de310139d888c952206fd5e3fc133605526de9&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:commit-50de310139d888c952206fd5e3fc133605526de9&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~2 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
site-settings        -34 B  (-0.0%)       +2 B  (+0.0%)
settings             -34 B  (-0.0%)       +2 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[wojtekn]

Works as expected. The code change looks clear.