feat: check asynchronous actions in pollora:doctor and Site Health

[ogorzalka]

Phase 4 of Async Actions, step 1: a doctor check (async-actions, console and Site Health) for the failures asynchronous actions never show.

Errors

• #[Async] declarations discovery ignored: they were only logged, they are now kept in AsyncDeclarationFailures (registrar, HookDiscovery, Action::handle()).
• The default driver is unavailable: every handler then runs inside the request.

Warnings

• A via() driver is unavailable (the action falls back to the default driver).
• HOOKS_ASYNC_CONNECTION names an undefined connection, or a sync/null one (auto then leaves the queue out).
• WP-Cron events overdue for more than an hour while WP-Cron or Action Scheduler is in use. Pollora sets DISABLE_WP_CRON, so these drivers need a system cron requesting wp-cron.php. The check relies on overdue events (WordPress core always schedules some), not on the constant alone, so a site with a working system cron gets no false warning.
• Jobs of a database queue waiting 15 minutes with no worker (the safeguard promised in feat: leave the Laravel queue out of auto until a connection is set for async actions #429). Other queue drivers are not inspected.
• Stored payloads older than a day with no event, and unique locks expired for more than a day: the daily pollora/async/recover task does not run.

AsyncInspector holds every WordPress/database read. It finds registrations in $wp_filter (both ->async() and #[Async]), so pollora/hook needs no change. It will also serve pollora:async:list.

Tests: AsyncActionsCheckTest (11), AsyncInspectorTest (6, including the jobs table in SQLite), AsyncAttributeTest updated; the Site Health E2E expects the "Asynchronous actions" label. 1891 tests pass, PHPStan clean.