fix(cron): preserve actionable drift recovery alerts

[sashmatash]

What changed

• Keep the unpinned provider/model drift guard before agent construction and inference.
• Preserve explicit pin/update guidance for recurring or otherwise repeatable jobs.
• Tell consumed finite one-shots to create a new future job with an explicit provider and model.
• Deliver those lifecycle-specific actions before the generic 180-character failure-summary truncation.
• Correct the cron documentation so cronjob action=update is not presented as a remedy for a consumed finite one-shot.

Why

A finite one-shot is consumed when its dispatch is claimed, even if the later drift guard blocks inference. The existing update-oriented recovery advice therefore pointed to a job that could no longer be updated. The generic chat failure summarizer also truncated both recreation and update guidance before users could see it.

This is a focused follow-up to #44585.

How to test

scripts/run_tests.sh \
  tests/cron/test_cron_provider_pin.py \
  tests/cron/test_scheduler.py \
  tests/cron/test_jobs.py -q

Result: 396 passed, 0 failed.

Additional verification:

• Regression tests were observed failing before the delivery-summary fix and passing afterward.
• Mocked finite and repeatable probes both failed closed before AIAgent construction and delivered the correct lifecycle-specific action.
• git diff --check passed.
• Independent read-only review returned APPROVED with no blockers, suggestions, or nits.

Platform tested

• macOS 26.5.2
• Python 3.11.14

Notes

The repository-wide suite and Docusaurus build were not run. The documentation change is a single Markdown line; CI remains the authority for full-repository compatibility.

[teknium1]

Thanks for preserving the actionable drift alert; the underlying lifecycle issue is present on current main.

Problems

• The proposed repeatable-job instruction uses cronjob action=update ... provider=<provider> model=<model>. Current main intentionally ignores those agent-facing arguments in tools/cronjob_tools.py:1089-1093; tests/tools/test_cronjob_tools.py:411-444 verifies an agent-dispatched update leaves an existing pin unchanged. The new alert and docs would therefore recommend a recovery action that cannot pin the job.
• The added tests do not exercise the lifecycle ordering behind the report. The production path claims a finite one-shot before run_job() (cron/scheduler.py:3897-3904), and claim_dispatch() persists the consumed count (cron/jobs.py:1828-1884).

Suggested changes

• Use the supported user-owned recovery surface in alert text and docs: dashboard or hermes cron edit <job_id> --model ... --provider ...; retain new-job guidance for consumed one-shots.
• Add one scheduler-level regression covering claim → drift failure → delivery, with no AIAgent construction.

Automated hermes-sweeper review.

[teknium1]

Merged via PR #85508 (rebase-merge) — your commit was cherry-picked onto current main with your authorship preserved in git log.

You were the earliest submitter of the drift-alert delivery fix (untruncated, lifecycle-aware remediation), 18 days ahead of the overlapping work — your one-shot-vs-recurring remediation logic and the docs correction landed as you wrote them, reconciled with the newer alert-once dedup machinery. Thanks!