Make schedule time-zone behavior explicit and deterministic

[elkampu]

Goal

Daily and weekly capture windows use the host's local time zone. Containers commonly default to UTC, but the UI does not identify the active zone and tests cannot select one explicitly.

Required time-zone policy

• For a nonexistent spring-forward wall time, move forward by the DST gap.
• For an ambiguous fall-back one-time start, choose the earlier UTC occurrence.
• Both repeated-hour instants are inside a recurring window whose wall-clock bounds include them.
• One-time starts remain stored UTC instants. Daily/weekly windows remain wall-clock values evaluated in the active startup time zone.
• Changing TZ requires restart and changes future recurring evaluations, not stored one-time starts.

Acceptance criteria

• The New session and System check pages display the active time-zone ID and the offset calculated at TimeProvider.GetUtcNow().
• CaptureScheduleService receives an explicit TimeZoneInfo dependency rather than reading TimeZoneInfo.Local directly.
• CaptureScheduleService and Sessions/Create use the same injected time zone for local-to-UTC conversion and the same TimeProvider for future validation instead of DateTime.Now.
• Tests inject a deterministic DST-capable TimeZoneInfo; they never depend on the CI host's local zone.
• Tests cover the spring-forward and fall-back rules above, an overnight window, and UTC.
• Docker documentation explains how to set TZ, what happens when it is omitted, and the restart behavior.
• Existing persisted UTC start times remain backwards compatible.

Please comment with your proposed time-zone abstraction and compatibility plan before starting. A draft PR is welcome.

[iibaranov-IG]

Proposed abstraction and compatibility plan:

• resolve TimeZoneInfo.Local once at startup and register that concrete TimeZoneInfo as the application-wide recurring-schedule zone alongside the existing TimeProvider
• inject both dependencies into CaptureScheduleService and Sessions/Create, removing direct DateTime.Now / TimeZoneInfo.Local reads
• centralize wall-time conversion: invalid spring-forward values advance minute-by-minute through the gap; ambiguous one-time starts choose the larger offset (earlier UTC instant)
• evaluate recurring daily/weekly membership in wall-clock time so both repeated-hour UTC instants map inside matching bounds; keep persisted one-time starts untouched as UTC
• expose a shared zone label with the offset computed at TimeProvider.GetUtcNow() on New session and System check
• use custom deterministic DST rules in tests for spring gap, fall ambiguity, repeated-hour membership, overnight windows, and UTC
• document TZ startup/restart semantics for containers and preserve all existing JSON fields.