fix(cron): cap LLM job iterations separately

[Dev-TechT]

Summary

• add a cron-specific max_iterations cap for LLM-backed scheduled jobs
• stop cron runs from inheriting large interactive agent.max_turns values by default
• document cron.max_iterations / HERMES_CRON_MAX_ITERATIONS and cover default, override, invalid, and run-job propagation paths

Why

A high interactive turn limit is useful in chat, but a recurring cron job inheriting it can monopolize the gateway cron ticker and delay unrelated due jobs. Cron should have a conservative scheduler-safe default unless the operator explicitly opts into a higher cron-specific limit.

Test Plan

• python -m pytest tests/cron/test_cron_inactivity_timeout.py::TestCronRunLimits -q -o 'addopts=' -> 6 passed
• python -m pytest tests/cron/test_cron_inactivity_timeout.py -q -o 'addopts=' -> 17 passed
• python -m py_compile cron/scheduler.py tests/cron/test_cron_inactivity_timeout.py hermes_cli/config.py -> passed
• git diff --check -> passed
• broader cron signal: python -m pytest tests/cron/test_cron_inactivity_timeout.py tests/cron/test_scheduler.py -q -o 'addopts=' -> 142 passed, 3 failed in existing Matrix delivery-target expectations unrelated to this diff (thread_id / extra Matrix home channel pollution)

Notes

• This intentionally changes the default for LLM-backed cron jobs: operators who need a higher cron cap can set cron.max_iterations or HERMES_CRON_MAX_ITERATIONS.
• Fork PR workflows are waiting for upstream authorization, so GitHub Actions currently show action_required with no runnable jobs.

[teknium1]

Thanks for isolating the cron-agent iteration resolution and adding propagation coverage.

Problems

• The claimed ticker-starvation failure mode is no longer present on current main: the production in-process scheduler calls tick(..., sync=False) at cron/scheduler_provider.py:179, and cron/scheduler.py:3704-3761 dispatches jobs to persistent pools without waiting. A cron-specific cap may still be useful for cost control, but the rationale should be updated to the current execution model.
• The new documented HERMES_CRON_MAX_ITERATIONS override conflicts with the non-secret configuration rule in AGENTS.md:102-106; behavioral settings belong in config.yaml.
• The proposed test hard-codes the default 30. Prefer asserting the behavioral relationship—that cron does not inherit a large agent.max_turns—over freezing a default literal.

Suggested changes

• Re-scope to the verified cost/control objective, use cron.max_iterations as the configuration surface, and update the resolution tests accordingly.

Automated hermes-sweeper review.

[teknium1]

Please do not add the documented HERMES_CRON_MAX_ITERATIONS override. AGENTS.md:102-106 requires non-secret behavioral settings to be configured through config.yaml; keep this feature on cron.max_iterations only.