Remove Store Subscriber Email as ID

[n7studios]

Summary

Follow-up to #1136 which required signed subscriber IDs for tag-restricted content.

Removes the kit/v1/subscriber/store-email-as-id-in-cookie REST API endpoint and the related JS that called it on Kit Form submissions to store the submitted email address' subscriber ID as a cookie. The endpoint was flagged in the reported vulnerability as an unauthenticated identity lookup: an attacker knowing a subscriber's email could obtain their numeric subscriber ID and set the ck_subscriber_id cookie without proof of email ownership.

After #1136, that numeric ID can no longer be used to bypass gated content. However, it can still be used for:

• Custom Content shortcode: displays personalised content based on a subscriber's tags
• Add a Tag on visit: tags the visitor when they view a Page/Post/CPT with the setting enabled

An attacker able to forge a subscriber identity via this endpoint could therefore view another subscriber's personalised Custom Content, and self-add to any tag the creator uses for "Add a Tag on visit" (potentially triggering unintended automations).

Removing the endpoint eliminates this residual identity-forging vector while preserving the primary way numeric subscriber IDs are populated - via the ck_subscriber_id URL parameter included in Kit email links. Creators using inline Kit forms without redirects will lose immediate personalisation on that same page view; personalisation continues to work on subsequent visits via email link.

If removing this functionality causes creator issues, it can safely be reinstated. At this stage, preferring signed subscriber IDs wherever possible is the more defensible position.

Testing

Removed Integration tests that exercised the removed REST endpoint (RESTAPITest, RESTAPIRestrictContentTest) and the EndToEnd Cest (SubscriberEmailToIDOnFormSubmitCest) that verified the JS flow.

Checklist

• I have written a test and included it in this PR
• I have run all tests and they pass
• The code passes when running the PHP CodeSniffer
• Code meets WordPress Coding Standards for PHP, HTML, CSS and JS
• Security and Sanitization requirements have been followed
• I have assigned a reviewer or two to review this PR (if you're not sure who to assign, we can do this step for you)