feat(cron): support per-job max_iterations override

[kpmfyi]

Summary

• Allows individual cron jobs to specify max_iterations in their job definition (e.g., in jobs.json)
• Overrides the global agent.max_turns / max_turns config on a per-job basis
• Follows the existing per-job override pattern already used by model, provider, and base_url

Fallback chain: job.max_iterations > config.agent.max_turns > config.max_turns > 90

Use case

Research/accumulation jobs that use web search and file tools often need 20+ iterations, while simple notification jobs only need 3-5. Currently all jobs share the same global limit, forcing a compromise that either wastes resources on simple jobs or constrains complex ones.

Example

{
  "id": "daily-research",
  "name": "Daily Research Digest",
  "prompt": "Research and compile...",
  "max_iterations": 25,
  "schedule": "0 8 * * *"
}

Test plan

• Job with max_iterations set uses that value
• Job without max_iterations falls back to global config
• Job without max_iterations and no global config falls back to 90

🤖 Generated with Claude Code

[teknium1]

Closing this one — the use case is real but too niche to justify expanding the cronjob tool schema further. The PR also only covers the scheduler read path; it would still need the tool schema parameter and create/update plumbing in cronjob_tools.py to be usable. The global max_iterations default works for most jobs, and jobs that need more room can be tuned via prompt design. Thanks for the contribution though!