Schedule backups in local time instead of UTC (0.66.0)

Schedule times were UTC, so a nightly 03:00 backup had to be entered as
01:00 or 02:00 depending on the season, and moved by an hour twice a year.

Each schedule now has an IANA time zone, preset in the form to the
browser's (e.g. Europe/Berlin), and its hour/minute/weekday are wall-clock
time there. compute_next_run builds each candidate day from its date in
that zone rather than adding 24 hours, so the time stays put across
daylight saving changes; a time skipped by the spring change runs an hour
later that day. next_run is still stored as naive UTC.

- Existing schedules default to UTC and keep their run times until edited.
- The API validates the zone and hour/minute/weekday ranges (400) instead
  of silently wrapping them.
- tzdata is a dependency: the slim base image has no system tz database.

Tests cover Berlin winter and summer time, both 2026 change days, the
skipped hour, a weekly run across the UTC date line, hourly at a +5:30
offset, the UTC fallback and the API checks.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/src/api/schedules.ts

@@ -12,6 +12,8 @@ export interface BackupSchedule {
   hour: number;
   minute: number;
   weekday: number;
+  /** IANA zone the time is in, e.g. "Europe/Berlin". */
+  timezone: string;
   include_volumes: boolean;
   stop_first: boolean;
   keep: number;
@@ -34,6 +36,7 @@ export interface ScheduleInput {
   hour: number;
   minute: number;
   weekday: number;
+  timezone: string;
   include_volumes: boolean;
   stop_first: boolean;
   keep: number;