Add per-automation timezones and catch-up semantics

[BelhsanHmida]

Problem

The current automation runner evaluates every cron expression in the global FLEXMEASURES_TIMEZONE and does not persist which scheduled occurrences have been handled.

As a result:

• users cannot choose the timezone in which an automation's cron expression should be interpreted;
• a scheduled time in the skipped local hour at the start of daylight saving time is missed;
• a scheduled time in the repeated local hour at the end of daylight saving time may run twice; and
• occurrences missed while the runner is unavailable are not caught up.

These semantics should be explicit and independent of how often the runner process happens to execute.

Proposed behaviour

• Store an IANA timezone on each automation.
• Default the timezone to FLEXMEASURES_TIMEZONE when an automation is created, preserving the current default behaviour.
• Persist enough scheduling state to identify the last handled scheduled occurrence.
• Interpret cron expressions in the automation's timezone.
• Treat an ambiguous repeated local time as one wall-clock occurrence, so it does not run twice merely because the UTC offset changed.
• Catch up a skipped or missed forecast occurrence once when the runner resumes.
• Coalesce multiple missed forecast occurrences into the most recent relevant occurrence instead of replaying every stale forecast.

Future automation types may need configurable catch-up policies such as skip, run-once, or replay, but that does not need to be generalised before another type requires it.

Acceptance criteria

• An automation stores and exposes a valid IANA timezone.
• Existing creation paths default the timezone to FLEXMEASURES_TIMEZONE when none is supplied.
• The runner persists its scheduling cursor or equivalent occurrence state across process restarts.
• Tests cover two automations with different timezones.
• Tests cover the skipped and repeated daylight-saving-time hours.
• Tests cover one missed occurrence and several missed occurrences during downtime.
• Forecast catch-up queues at most one current, useful forecast rather than replaying all stale occurrences.
• The behaviour is documented for CLI users and operators.

Out of scope

Retrying an occurrence that failed before or during job queueing requires durable run records and idempotency protection. That is tracked in the separate safe-retries follow-up issue.

Follow-up to #2288 and #2290. This work is part of the automation story #2334.