Fix race condition causing duplicate article generation

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>

includes/core/class-pipeline-runner.php

@@ -110,6 +110,16 @@ class PRAutoBlogger_Pipeline_Runner {
 			return;
 		}
 
+		// Persist the consumed queue BEFORE generating so the status poller
+		// cannot re-schedule a cron event for the same idea. Without this,
+		// the DB still holds the old queue during the ~90s generation window,
+		// and the poller's orphan-recovery logic duplicates the last article.
+		if ( ! empty( $queue['ideas'] ) ) {
+			update_option( self::QUEUE_KEY, $queue, false );
+		} else {
+			delete_option( self::QUEUE_KEY );
+		}
+
 		$worker         = new PRAutoBlogger_Article_Worker( $cost_tracker );
 		$article_result = $worker->generate( $idea );