Fix invalid HERMES_CRON_TIMEOUT fallback in cron jobs

[cola-runner]

Summary

• parse HERMES_CRON_TIMEOUT defensively instead of calling float(...) inline in run_job()
• keep 0 as the unlimited sentinel, but fall back to the default inactivity timeout when the env var is malformed
• add regression coverage for valid, unlimited, and invalid timeout values via the shared scheduler helper

Closes #11319.

Testing

• source venv/bin/activate && python -m pytest tests/cron/test_cron_inactivity_timeout.py tests/cron/test_scheduler.py -q
• source venv/bin/activate && python -m pytest tests/ -q (environment still has existing unrelated failures/errors in ACP, web server optional deps, transcription optional deps, and several pre-existing gateway/run_agent tests; the new cron regression is not among them)

[alt-glitch]

Competing PRs for #11319: see also #11365 and #11328. Maintainer should pick one.

[cola-runner]

Rebased on main and tightened the helper:

• Dropped the redundant negative-value warning branch — restored the original semantics where any non-positive `HERMES_CRON_TIMEOUT` is unlimited (matching the pre-fix `if _cron_timeout > 0 else None`).
• Narrowed `except Exception` → `except ValueError` (the only thing `float()` can raise on string input).
• Added regression tests for negative-as-unlimited and whitespace-as-default.

Net: 22 insertions / 19 deletions — smaller than the prior version and one fewer warning path.

[teknium1]

Thanks for the fix! Closing as a duplicate — #11365 (from @yeyitech, submitted ~45 minutes earlier) fixes the same issue with the same defensive parse pattern. Salvaged it onto current main in PR #17515, now merged:

#17515

Both of you independently identified and fixed the same bug the same way; credit to both. Really appreciate you taking the time to write the regression coverage.