Warn when WP-Cron cannot run the background queue

[ajaydsouza]

Target release: 1.1.0

Problem

Processor::maybe_schedule() is the entire background story, and lazy_convert feeds it. On a site with DISABLE_WP_CRON set, or with a broken loopback request, the scheduled event never fires and the queue never advances.

There is no signal anywhere that this has happened. The Bulk Optimize screen shows "Waiting in the queue: 4,182" indefinitely, with no reason given and nothing to suggest the fault is environmental rather than a broken plugin. This is the worst silent failure in the plugin: everything reports success, nothing happens.

Where it shows up in the code

• includes/class-processor.php:302 — wp_schedule_event() is the only thing standing between a queued attachment and a converted one.
• includes/frontend/class-rewriter.php — flush_lazy_queue() calls Processor::maybe_schedule(), so first-view conversion depends on the same mechanism.
• Nothing in includes/ references DISABLE_WP_CRON.

Proposed solution

Detect the condition and say so, rather than trying to work around it.

• Treat cron as suspect when DISABLE_WP_CRON is defined and truthy, or when a scheduled wzio_process_queue event's timestamp is well in the past while rows are still pending.
• Show a notice on Media → Bulk Optimize explaining that the background worker cannot run, and pointing at wp wzio run or a real system cron entry as the fix.
• Keep the foreground AJAX batching on that screen working exactly as it does now, since that path does not depend on cron.

Tasks

• Add a cron-health check (constant plus overdue-event detection)
• Surface it as a notice on the Bulk Optimize screen
• Mention the WP-CLI fallback and a system cron example in the notice
• Cover the overdue-event detection with a unit test

Notes

The same check should be reused by the Site Health tests in #9, but this issue stands alone and should not wait for it.