fix(scheduling): lock flow schedule reconcile before boot(), not after

[chubes4]

Closes #3492

Summary

The v0.176.8 deploy took the whole Extra Chill network down for ~45 minutes because FlowRoutines::reconcile() called self::boot() (a full ~700-routine registration pass through the Agents API Action Scheduler bridge) before any lock was taken. Only the registry's own reconcile step was guarded, so every one of 60 concurrent php-fpm workers paid the full boot() cost before finding out the registry lock was already held — and lock contention was misclassified as failure, so the deploy marker was retained and every subsequent request repeated the same cost. Under that load a RedisException from update_option() inside the Action Scheduler bridge escaped boot() before HashGatedRoutineBackend::persist() ran, losing that request's fingerprints and making the next boot() reschedule everything again — self-sustaining until the DB pinned out.

Changes

1. Lock before boot. Restored FlowScheduleReconciliationLock — a compare-and-set $wpdb->query() option lock with an explicit wp_cache_delete() (not add_option()/delete_option(), which can leave a stale object-cache-only entry that blocks forever — this was observed on the underlying agents-api registry lock during recovery). It was deleted by refactor(scheduling): converge flow and system-task scheduling on Agents API Routines #3475's routines convergence, along with its production class but not its smoke test (tests/flow-schedule-reconciliation-lock-smoke.php), which has been silently broken (require_once a file that no longer existed) since that PR landed. FlowRoutines::reconcile() now acquires this lock before calling boot(). A losing caller returns immediately with success => true, skipped => true, reason => 'locked', having done zero registry or Action Scheduler work.

2. Lock contention is not failure. datamachine_reconcile_marked_flow_schedules() (soon datamachine_run_deferred_flow_schedule_reconciliation(), see WP_Abilities_Registry::register called incorrectly - missing 'category' string in ability properties #3) treats a skipped result as a silent no-op: marker untouched, nothing logged. Only a genuine failure retains the marker, and it now arms a 5-minute backoff transient so a persistently failing reconcile doesn't re-enqueue on every request.

3. Moved off the request path. init no longer runs reconcile(true) inline — it only enqueues a single Action Scheduler async action (deduplicated with as_has_scheduled_action()), and the actual reconcile runs inside that action's callback. The WP-CLI path (wp datamachine flows reconcile-schedules --apply) still calls FlowRoutines::reconcile() synchronously, and now prints a clear message when it loses the lock race instead of reporting a misleading empty "success".

4. persist() survives a throw. boot()'s registration loops now run inside a try/finally so HashGatedRoutineBackend::persist() always runs, and each routine's registration has its own try/catch so one throwing registration (e.g. the Redis exception from the incident) logs and continues instead of silently losing every fingerprint recorded so far that request.

Testing

Two new pure-PHP smoke tests (existing style — no PHPUnit/WP bootstrap):

• tests/flow-routines-reconcile-lock-before-boot-smoke.php — proves (a) a held lock makes reconcile() skip without ever calling boot() or persist(), and that normal operation resumes once released; (c) boot() persists once even when a registration throws (loop continues to the next routine), and persists via its top-level finally even when an unexpected throw outside the per-routine catch propagates out of boot().
• tests/flow-schedule-reconciliation-worker-smoke.php — proves (b) the init handler never calls FlowRoutines::reconcile() itself (only enqueues, deduplicated against an already-pending action), a locked/skipped worker result is a silent no-op, (d) a genuine failure retains the marker and arms the backoff transient (and the init handler respects it), and (e) a genuine success clears the marker and logs completion.

Ran:

php tests/flow-routines-reconcile-lock-before-boot-smoke.php   # 19/19 pass
php tests/flow-schedule-reconciliation-worker-smoke.php        # 18/18 pass
php tests/flow-schedule-reconciliation-lock-smoke.php          # 13/13 pass (previously broken by #3475's dangling require)
php tests/setup-schema-runtime-smoke.php                       # pass, unaffected

composer lint (WordPress-Extra standard — this repo has no phpcs.xml, so I diffed against the pre-existing per-file baseline rather than a bare phpcs run against PSR2 defaults, which flags unrelated pre-existing style across the whole codebase): every touched production file is clean relative to its pre-existing baseline. The one alignment issue my own change introduced (ReconcileFlowSchedulesAbility.php's new skipped/reason output-schema keys) was fixed with phpcbf.

Not in scope / follow-ups

• The agents-api registry's own agents_routine_reconcile_lock still uses add_option()/delete_option() and has the same stale-object-cache failure mode this PR's lock is designed to avoid. That's an agents-api issue, filed separately per the network's layer-purity convention — not fixed here since it's owned by a different repo/layer.
• The ~300k leaked agents_routine_action_generation_* option rows observed during recovery are also an agents-api-side leak, out of scope for this DM-side fix.

AI disclosure

This PR was authored by an AI coding agent (Extra Chill Bot / Claude) per repository convention.