fix(cron): only advance next_run_at for jobs that are actually dispatched

[wildnewton]

Problem

When a cron job is silently skipped (not dequeued for execution because it's already running from a previous tick), the scheduler still advances next_run_at via advance_next_run(). This means the job never retries and appears to have run when it hasn't.

Evidence: job 488dec122600 was skipped at 2026-07-08 21:00 and next_run_at advanced to 2026-07-09 without execution.

Root Cause

In tick(), advance_next_run() was called for ALL due jobs BEFORE the in-flight dedup guard (_submit_with_guard). When a job was skipped (already in _running_job_ids), its next_run_at had already been advanced.

Fix

Move advance_next_run() from the pre-dispatch loop into _submit_with_guard, calling it ONLY when the job is successfully claimed for dispatch (not already running). Skipped jobs keep their next_run_at unchanged so they are retried on the next tick.

Changes

• cron/scheduler.py: Move advance_next_run from pre-dispatch loop into _submit_with_guard, only after successful claim
• tests/cron/test_scheduler.py: Add two tests:
  • RED: skipped job must NOT have advance_next_run called
  • GREEN: dispatched job still has advance_next_run called (at-most-once semantics preserved)

TDD Commits

1. test(cron): RED — skipped job still has advance_next_run called
2. fix(cron): only advance next_run_at for jobs that are actually dispatched

[teknium1]

Thanks for isolating the pre-guard advancement bug; current main still has it at cron/scheduler.py:3554-3560, before the already-running return at cron/scheduler.py:3627-3630.

Problems

• cron/scheduler.py:2937 advances before pool.submit at :2948. Current main now handles a shutdown race where pool.submit fails and releases the in-memory claim (cron/scheduler.py:3641-3653) so the job stays due. The proposed ordering would still persist an advance when that submission never succeeds, contrary to the PR's "actually dispatched" contract.

Suggested changes

• Integrate this move with the current guarded submission path so rejected submissions leave next_run_at unchanged without introducing a worker-start race.
• Add a regression test for a pool.submit shutdown failure asserting advance_next_run was not called, in addition to the already-running case.

Automated hermes-sweeper review.

[teknium1]

advance_next_run still runs before pool.submit. Current main has a shutdown-race path where submission fails and the in-memory claim is released; in that case this persistent advance means a job that was never enqueued is no longer due. Integrate this with the current submit-failure handling and add a regression test.