fix(cron): bound tick cost and make every accepted schedule fire

[TheGreatAxios]

Summary

• Each expression is parsed once into allowed-value sets (parseCronExpression), capped at 256 characters and 64 comma clauses. A 5,000-clause expression is rejected at parse time instead of costing minutes of CPU per tick.
• The next-fire search skips non-matching days and hours, so it costs a few steps per day. The lookahead is eight years plus a day, which covers Feb 29 across 2100.
• The ticker asks whether any minute after lastFiredAt (or createdAt) and at or before now matches, and only searches the last lookahead window. A Feb 29 schedule now fires, and an old anchor costs no more.
• POST / rejects an expression that can never fire (cronExpressionCanFire, now arithmetic). The ticker stops such a row with stoppedReason: "invalid_expression" and calls onScheduleStopped, instead of re-scanning it.
• n/step without a range end steps to the field maximum (5/2 → 5,7,…,59).
• DOM/DOW Vixie OR semantics are unchanged.

Stacked on #18.

Verification

bun run check, build, test:e2e against local Postgres, and the Node pack smoke pass. The new unit and e2e tests fail on #18 first. They cover 5/2, the caps, never-firing expressions, Feb 29 (unit and e2e), OR semantics, and timing bounds.

Closes CL-9447