The status poller's orphan-recovery logic re-scheduled cron events for
articles already being generated. During the ~90s generation window, the
queue option in the DB still contained the in-progress idea because the
process only deleted/updated it AFTER generation completed.
Fix: persist the consumed queue to the DB BEFORE starting generation.
When the poller checks get_option(), it now sees either an empty queue
(for the last article) or a queue without the current idea, so orphan
recovery cannot duplicate work.
Root cause: process_next_queued_article() did array_shift on a local
variable but left the DB unchanged until after the slow LLM+image
generation finished. The poller saw the stale DB state, assumed the
cron event had died, and re-scheduled it — producing a 4th post from
3 ideas on every run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
00cfb39253