Signup fails or emails not sent for certain email formats ("+", ".", "_")

[hanna-meda]

Describe the bug
Signup behavior is inconsistent depending on the email format used. Certain valid email formats either fail silently or behave differently compared to signup via the plugin's website.

To Reproduce
Steps to reproduce the behavior:

1. Install and activate the Imagify plugin.
2. Click on the "Sign up, it's free!" banner.

Case 1: Emails with dots or underscore
Example:

• film.simleu_21@gmail.com,
• beatrix.arc.21@gmail.com
  => user is created, but emails are not sent

Case 2: Emails with "+" aliasing
Example:

• hanna+may21@wp-media.me
  => "Congratulations" message is shown in UI, but user is not created, no emails are sent

Control case (works as expected)
Example:

• tzinkeh@yahoo.no
  => user is created and emails are sent

Comparison with website (https://app.imagify.io/account/sign_up/)
Note: When performing the same signup cases via the website, users are created in all cases and emails are sent in all cases.

Expected behavior
All valid email formats (including "+", ".", "_") should be accepted
User creation and email sending should be consistent with website behavior

[Miraeld]

The + aliasing case is fixed in #1259.

Mechanism, for the record: the signup modal concatenated the raw address into the AJAX query string, where a literal + decodes to a space. sanitize_email() then stripped that space rather than rejecting it, turning hanna+may21@wp-media.me into the perfectly valid hannamay21@wp-media.me. So an account really was created - just for an address nobody typed, with the API key mail going to a mailbox the user cannot read. That is why the UI showed "Congratulations" while nothing arrived.

Fixed on both sides: the client now percent-encodes the address, and the handler refuses any address that sanitization had to alter, so this cannot happen silently again from any caller.

The dots/underscores case is a different problem and is not plugin-side: those characters are valid in a local part and survive both the query-string decoding and sanitize_email() untouched. #1259 adds a test proving the plugin sends them to the API unchanged, so the break is in the API or the mail service. Tracked separately as #1260 so this fix is not held up by it.