fix(cron): add seconds support and honor sub-minute schedules

[bitflicker64]

Summary

Fixes #44749. Relative schedules like "in 10 seconds" were broken in two places:

1. LLM fabricates absolute timestamps. The system prompt only injects the date (for caching), so models invent something like 12:35 for "now + 10s" and the job never fires.
2. parse_duration rejected seconds. Even a correct "10s" schedule raised ValueError.

This PR adds seconds support and makes the built-in ticker actually honor those schedules.

Changes

cron/jobs.py

• parse_duration accepts s / sec / secs / second / seconds
• Allows decimal values (1.5s, 0.5m)
• Returns float minutes so sub-minute precision is preserved
• seconds_until_next_job / compute_ticker_wait_seconds for adaptive sleep

cron/scheduler_provider.py

• Built-in ticker still defaults to a 60s cadence when nothing is due soon
• When a job is due sooner, wait shortens to that job's next_run_at
• Rechecks every second so a job created mid-cycle (e.g. "remind me in 10s") still fires on time

tools/cronjob_tools.py

• Schema examples include 10s / 30s
• Explicit warning: do not invent ISO timestamps for relative times; use duration format instead

Docs

• website/docs/user-guide/features/cron.md documents seconds formats and adaptive wake

Review follow-up

Earlier feedback correctly pointed out that advertising 10s while the ticker slept a fixed 60s could not honor the promised resolution. This update keeps the seconds parser and adds the trigger path plus an end-to-end test that a 2s one-shot fires in under ~6s with interval=60.

Test plan

• parse_duration("30s") == 0.5
• parse_duration("90seconds") == 1.5
• parse_schedule("every 30s") / "30s" / "1.5m"
• TestTickerWait (no jobs, near-term shortens wait, overdue near-zero, paused/disabled ignored)
• test_inprocess_provider_honors_subminute_schedule (e2e dispatch path)
• Existing scheduler-provider suite green (61 tests)

.venv/bin/python -m pytest tests/cron/test_scheduler_provider.py \
  tests/cron/test_jobs.py::TestTickerWait \
  tests/cron/test_jobs.py::TestParseDuration \
  tests/cron/test_jobs.py::TestParseSchedule -q

[teknium1]

Thanks for addressing the missing relative-duration path. Current main still rejects 10s in cron/jobs.py:465, so the premise is valid.

Problems

• The default trigger cannot honor the new advertised timing. InProcessCronScheduler.start() calls cron_tick() and then stop_event.wait(interval) with interval=60 by default (cron/scheduler_provider.py:166-194). Therefore 10s and 30s schedules can wait until the next 60-second tick.
• The added parser tests do not exercise that dispatch path, so they do not verify the requested timing guarantee.

Suggested changes

• Align the accepted schedule resolution with the built-in trigger, or add a trigger mechanism and an end-to-end timing test that can honor sub-minute jobs.
• Update website/docs/user-guide/features/cron.md:526-540 if seconds become a supported user-facing format.

Automated hermes-sweeper review.