fix(activator): register cron_schedules filter during activation

Dispatcher::register_hooks() runs on plugins_loaded, which is AFTER
register_activation_hook fires. The custom recurrence 'cf7stg_every_minute'
was therefore unknown to wp_schedule_event during activation, and the
'cf7stg_dispatch' event silently failed to schedule — queue items never
got dispatched.

Pilot caught this on washanyanya.ru (23 items queued, 0 sent, 0 failed —
no cron hook firing at all).

Adding the filter directly inside Activator::schedule_events() makes the
custom schedule available in the same request as the wp_schedule_event
call, regardless of bootstrap order.

After updating the plugin, deactivate + reactivate is required to
re-trigger Activator::activate() so events get (re)scheduled.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/superpowers/plans/2026-04-17-cf7-spam-to-telegram.md

@@ -2246,6 +2246,13 @@ final class Activator
 
     private static function schedule_events(): void
     {
+        // Register the custom 60-second schedule here — Dispatcher::register_hooks()
+        // runs on plugins_loaded, which is AFTER activation. Without this filter
+        // being in place during activate(), wp_schedule_event with an unknown
+        // recurrence ('cf7stg_every_minute') silently fails and the event never
+        // fires.
+        add_filter('cron_schedules', ['\\Cf7stg\\Dispatcher', 'register_schedule']);
+
         if (!wp_next_scheduled('cf7stg_dispatch')) {
             wp_schedule_event(time() + 60, 'cf7stg_every_minute', 'cf7stg_dispatch');
         }