Restrict notification subscriptions and harden the webhook sender

[GaryJones]

Summary

Two pieces of defence-in-depth in the notifications module.

The subscription picker only ever offers users who can publish_posts, but both save paths — the AJAX handler and the post-save form handler — stored whatever user IDs arrived in the request. An authorised editor could therefore add arbitrary users (a plain subscriber, say) as followers of a post. Both paths now intersect the submitted IDs with that same publish_posts candidate set before saving, so only users the picker would offer can be subscribed. The users auto-subscribed by the plugin (the current user and the post author) go through a separate path and are unaffected.

Separately, send_to_webhook() sent the payload with wp_remote_post() and, on failure, called print_ajax_response() which ends in wp_die(). That notification fires on post transitions and editorial-comment insertion, which are not always AJAX requests, so a failing webhook could abort an otherwise valid save. It now uses wp_safe_remote_post() — which validates the URL and rejects private, loopback and link-local hosts (SSRF) — and on failure fires an ef_notification_webhook_failed action for logging and returns rather than dying.

Fixes VIPPLUG-20.

Test plan

• composer test:integration -- --filter NotificationsTest — a user the picker would not offer is not subscribed; a failed webhook returns without aborting.
• All notifications tests still pass (61 tests across the Notifications* classes).
• PHPCS and php -l clean.
• Manual: as an editor, subscribe a teammate (works) and confirm the saved followers never include non-editorial users; point the webhook at an unreachable URL and confirm post saves still succeed.