fix: normalize cron repeat updates

[hanzckernel]

Fixes #15582

Related:

• fix(cron): normalize repeat integer updates to dict format #15590 and fix: normalize repeat field in update_job() to prevent TypeError (#15582) #15682 — earlier attempts for the same root bug. This PR keeps the scalar-repeat normalization but adds the missing API validation, null clearing, completed-count preservation, and legacy persisted-state repair.
• [TESTED FIX] TypeError when repeat='once' passed to cronjob create (string-to-int coercion missing) #7142 / fix(cron): normalize string repeat values #7216 — adjacent string repeat coercion work. This PR keeps API update semantics stricter: invalid update values are rejected instead of silently coercing arbitrary strings.
• Bug: cron.jobs.update_job crashes when schedule updates use raw string form #13706 — schedule-field version of the same API/raw-form vs internal-shape bug pattern.
• fix: 修复 cron job 编辑 payload contract EKKOLearnAI/hermes-studio#364 — frontend cron edit payload-contract fix that should pair with this backend normalization.

Cron repeat updates now stay in the canonical scheduler shape even when callers use Web UI/API-style scalar or null payloads.

Changes

• Normalize repeat updates into { times, completed } instead of persisting raw scalar values.
• Preserve the existing completed-run count when changing or clearing the repeat limit.
• Allow repeat: null on update to clear a repeat limit.
• Reject invalid API update repeat values (0, negative numbers, strings, floats, booleans).
• Normalize legacy scalar repeat values on get_job, list_jobs, and mark_job_run, so already-corrupted persisted jobs do not wait until the next run to fail.
• Add regression coverage across cron storage, API update validation, and the cronjob tool list path.

Why

The Web UI edit surface sends repeat as a scalar integer or null, while cron jobs are stored with repeat metadata as an object. Without backend normalization, a PATCH such as { "repeat": 3 } can persist repeat: 3; the next run then crashes when repeat accounting expects .get() / completed.

Earlier fixes covered the core scalar-to-dict path, but not all edge cases seen from the Web UI/API boundary. This PR is intended to supersede those variants with the full persisted-state contract covered in tests.

Verification

Passed:

./scripts/run_tests.sh tests/cron/test_jobs.py tests/gateway/test_api_server_jobs.py tests/tools/test_cronjob_tools.py
./scripts/run_tests.sh tests/cron tests/hermes_cli/test_web_server.py
python -m py_compile cron/jobs.py gateway/platforms/api_server.py
git diff --check

Results:

• 144 passed, 42 warnings for targeted cron/API/tool tests
• 431 passed for broader cron + web-server coverage
• py_compile passed
• diff check passed

Known:

• gh pr checks currently reports no checks for this branch, so local verification above is the available gate.

[teknium1]

Thanks for tracing the scalar-repeat mismatch; the premise is still valid on current main: gateway/platforms/api_server.py:3672 forwards PATCH values to cron/jobs.py:update_job, which directly merges updates at cron/jobs.py:1220.

Problems

• Current one-shot execution calls claim_dispatch() before mark_job_run() (cron/scheduler.py:3372). claim_dispatch() reads raw persisted repeat and calls .get() at cron/jobs.py:1494-1497, so a legacy scalar one-shot can still fail before the proposed mark-time repair runs. _get_due_jobs_locked() has the same raw-map assumption at cron/jobs.py:1814-1817.
• The diff also adds per-job profile storage (cron/jobs.py:671-692, :798-853) without a scheduler consumer or API exposure. That is unrelated to the stated fix and leaves dead persisted state.

Suggested changes

• Salvage repeat normalization onto current update_job, then cover all raw scheduler consumers while preserving the current pre-claim one-shot invariant.
• Add an API-to-storage-to-one-shot-claim regression, and drop the unrelated profile delta.

This is an automated hermes-sweeper review.

[teknium1]

This protects new updates, but current main's claim_dispatch() reads the raw stored value and calls .get() before mark_job_run() executes (cron/jobs.py:1494-1497). Extend legacy repair to that pre-run path and add a scalar one-shot regression.

[teknium1]

This profile plumbing is outside the repeat fix. The PR-head scheduler has no job-profile consumer and the API allowlist does not expose profile; please drop it from this PR or land it separately with an execution-path implementation and tests.