Keep cron fire history out of scheduler scans

[16francej]

Summary

• store cron fire history in a dedicated durable table instead of inline cron records
• migrate existing inline history without dropping retention
• page run-history reads while keeping scheduler list/get calls lightweight

Why

Scheduler scans read cron metadata frequently but never need fire history. Keeping an ever-growing history array inside each cron makes every scan clone unrelated historical payloads and can amplify memory use.

Verification

• formatting, ESLint, oxlint, and TypeScript checks
• focused cron/API tests
• PostgreSQL migration, paging, and cross-process persistence tests
• concurrent old-writer/new-migrator rollout test
• two-instance queue test
• live browser flow: create cron, scheduled fire, manual fire, and run-history UI
• direct database check: cron rows contain no inline fireLog; both fire records remain in the history table

Rollout

Deploy new replicas with background work disabled, route traffic to them, then enable background work and demote old replicas. This keeps old API readers serving until the new readers own traffic; the first active scheduler then performs the atomic history cutover.

History retention remains indefinite and worker concurrency is unchanged.