fix(cron): reap stale execution claims before a one-shot hermes cron run dispatch

[ygd58]

Fixes #86721.

Root cause

hermes cron run <job_id> dispatches manual runs via _try_dispatch_background_run -> dispatch_async_delegation(role="cron_run", runner=_runner, ...). The runner thread lives in the calling process's shared daemon executor. When the one-shot process exits right after printing "Triggered job: ...", the in-flight runner dies mid-execution, leaving its cron/executions.db row permanently stuck at status='claimed' -- every subsequent hermes cron run on the same job then reports "Ran now: failed".

cron/executions.py already has the exact self-heal this needs: recover_interrupted_executions() correctly identifies and reclassifies stranded 'claimed'/'running' rows whose owner process has provably exited (checking both PID existence and process start-time, so a reused PID isn't mistaken for the original owner). But it was only ever called once, at the long-lived scheduler ticker's own startup -- a one-shot CLI invocation has no equivalent "startup" moment, so this self-heal never ran for it.

Fix

Added a call to recover_interrupted_executions() at the top of _try_dispatch_background_run, before any claim attempt -- mirroring exactly what the long-lived scheduler already does at its own startup, just triggered per one-shot invocation instead. Wrapped in try/except: pass (best-effort; a failure here must not block the actual dispatch).

Traced but did not attempt to fix the deeper "why does the runner die with the process at all" question -- that's the harder problem the issue's options 1/2 describe. This fix addresses the more urgent, clearly-scoped symptom: a stranded stale claim permanently blocking ALL future manual runs, using an already-correct existing implementation that just needed wiring into this call site.

Verification

Added 3 regression tests following the established real-subprocess dead-owner pattern already used in tests/cron/test_execution_ledger.py (a genuinely-dead PID, not a mock). Verified as a genuine regression by reverting the fix and confirming the unit test fails with recovery never having been called.

35/35 pass across the new test file plus two related existing test files (no regression).

[teknium1]

Merged via #86899 — your commit was cherry-picked onto current main with your authorship preserved in git log (merge commit bd3a966). We added a small follow-up on top replacing the bare except: pass around the recovery call with warning/debug logging, mirroring the scheduler tick's handling.

Nice find wiring recover_interrupted_executions() into the dispatch path — together with the tick-side reap from #86853 this closes both halves of #86721 (immediate self-heal on manual retry + periodic cleanup). The real-dead-PID regression tests were exactly right. Thanks!