fix(cron): bound schedules and due batches

[6iKUN6]

Problem

Closes #323.

/cron validated the numeric duration before unit conversion, so a finite input could overflow to Infinity in milliseconds and be reported as scheduled even though it could never become due. The Session job list and the aggregated due-job follow-up also had no total count or UTF-8 byte bounds.

Value

Cron scheduling now fails explicitly for unrepresentable times and keeps both Session memory and model-visible due delivery within fixed limits. Valid pending work is retained instead of being silently lost when one delivery batch reaches its budget.

Approach

• Require converted durations and initial absolute due times to be safe integers.
• Limit each Session to 64 active Cron jobs.
• Deliver at most 16 due jobs and 48 KiB of UTF-8 content per idle tick.
• Leave jobs outside the selected batch pending for later idle ticks.
• Advance only the jobs included in a successfully queued batch, preserving existing retry, one-shot, recurring, and idle-only behavior.

The limits are fixed runtime invariants rather than new user configuration. Batch selection preserves existing job order.

Validation

• bun run check — passed: config contract, discipline ledger, formatting, lint, and typecheck.
• bun run test — passed: 1113 tests, 0 failed, 1 skipped; the additional Vitest suite passed 30 tests.
• git diff --check — passed.
• Manual Pi smoke after /reload, with pi list showing only the local checkout:
  • /cron in 30s 回复：cron one-shot 已触发 scheduled and fired successfully.
  • /cron in 9007199254741s 不应创建 was rejected with an explicit duration warning.
• Job-count, due-batch count/byte bounds, pending retention, unsafe absolute due time, and delivery retry are covered by automated tests.

Impact

• User-visible behavior: oversized durations, unsafe absolute due times, and a 65th active job are rejected with warnings. Large simultaneous due sets are delivered across later idle polling ticks.
• Model-visible context: one Cron follow-up is bounded to 16 jobs and 48 KiB of UTF-8 content.
• Runtime/lifecycle: a Session retains at most 64 active jobs; only successfully delivered jobs advance.
• Persisted config/data: none. Cron jobs remain Session-local and in memory.
• Compatibility/risk: ordinary in and every schedules are unchanged. Only previously unbounded or unrepresentable inputs are rejected or split.

[6iKUN6]

@tt-a1i 麻烦有空帮忙 review 一下，谢谢。

[tt-a1i]

Verified exact head 2b22a2f. The duration and absolute-time checks, fixed Session/job delivery bounds, pending retention, and successful-delivery-only advancement preserve the Cron lifecycle while closing the correctness and resource-boundary gaps. Focused tests, repository checks, full tests, and current CI are green.