feat!: queue through the drivers of pollora/schedule

[ogorzalka]

pollora/hook 2.0, step 4 of the pollora/schedule plan.

WP-Cron and Action Scheduler are the drivers of pollora/schedule (v0.1.2, required). Async\Drivers\ScheduledDriver queues through them and keeps what is the hook's own: the message an event carries and where the payload lives. Async\Recovery is the daily task that was WpCronDriver::recover().

Breaking

Async\Drivers\WpCronDriver and ActionSchedulerDriver are removed, with no alias (the framework does not use them). WpCronDriver::handles()/claim() are PayloadStore's; the recovery constants and methods are Recovery's.

Unchanged

->async(), #[Async], Async::fake(), via() and their options; the hook pollora/async/run, the Action Scheduler groups (pollora or the queue name), identifier-only WP-Cron events and the pollora_async_ options. Work queued by 1.x runs once 2.0 is installed: tested on a real WordPress (an event with its option, an action in pollora, one in crm, queued under 1.4.1, run under 2.0).

Worth knowing

• Async::listen() keeps pollora/async/run and pollora/async/recover on WP-Cron through the pollora/schedule/protected_hooks filter, so via('wp-cron') still means WP-Cron when the site gave pollora/schedule another driver. Checked live with the site on Action Scheduler.
• Hook actions live in their own groups and never reach pollora/schedule's cron index (which follows its default group only): the index would otherwise drop them as stale.
• available() also waits for Action Scheduler to be initialised, so auto still falls back to WP-Cron before action_scheduler_init.
• The package now requires pollora/schedule, hence pollora/discovery (illuminate/collections, spatie/php-structure-discoverer), pollora/attributes, abilities and ajax.

264 tests, PHPStan clean.