[stevebauman]

RRULE schedules without DTSTART get a new default start each time the underlying library reconstructs the rule. This can restart a finite COUNT, shift an INTERVAL, and calculate occurrences in the application's timezone instead of the schedule's timezone. Changing a saved schedule's timezone also leaves next_run_at pointing to its old execution time.

Both RRULE drivers now resolve a missing start once, when the expression is first evaluated or serialized. The generated DTSTART and effective timezone are stored by addSchedule(), so reloading a schedule preserves its original timing. Explicit starts are left unchanged, and no database migration is required.

Saving a timezone change on an existing schedule now recalculates next_run_at from the current time. This applies to all drivers, preserves last_run_at, and keeps disabled schedules disabled with no next run. Local RRULE starts keep the same date and time in the new timezone, without resetting COUNT or INTERVAL.

Existing stored expressions without DTSTART still need an explicit intended start, since their original implicit start wasn't recorded. This is noted in the documentation.

Validated with the full Pest suite (135 tests) and Pint.

Fixes #19.