Workflows: timezone-aware schedules with automatic DST handling and next-run previews

## Problem

Buzz workflow schedules are expressed as cron or intervals without a first-class IANA timezone. An owner who wants a recurring workflow at a stable local wall-clock time must translate it to UTC and manually change it when daylight-saving time begins or ends.

This is operationally risky for human-facing routines. For example, a daily bootstrap intended for 3:45 a.m. in `America/Chicago` needs one UTC schedule during CDT and a different one during CST. Forgetting the seasonal edit either moves the routine by an hour or silently misses the intended operating window.

## Proposed Behavior

- Allow an optional IANA timezone such as `America/Chicago` on cron schedules in YAML, Desktop, mobile, and the CLI.
- Preserve the requested local wall-clock time across DST changes.
- Show the next three run times in both the selected timezone and UTC before saving.
- Define explicit behavior for the spring-forward gap and repeated fall-back hour, with a safe default and a configurable policy.
- Store the timezone and DST policy as part of the signed workflow definition.
- Keep existing timezone-less workflows backward compatible, with their current semantics clearly labeled.
- Surface the last run, next run, and timezone in the workflow UI and `buzz workflows get/list`.

## Acceptance Criteria

- A workflow scheduled for 3:45 a.m. in `America/Chicago` remains at 3:45 a.m. local time before and after DST transitions.
- Desktop, mobile, CLI, and relay calculate the same next-run instants from the signed definition.
- The save flow previews upcoming local and UTC run times.
- DST gap and repeated-hour behavior has deterministic tests.
- Existing schedules continue to run without migration surprises.

## Duplicate Check

Searched the current issue queue for `timezone`, `DST`, and `schedule timezone` on August 12, 2026. Related issues cover scheduled delivery and scheduler failures, but no open issue defines timezone-aware recurring workflows with DST handling and a next-run preview.

Start with the signed workflow definition and the existing cron/interval scheduling entry points exposed through YAML and `buzz workflows get/list`; trace how Desktop, mobile, CLI, and relay currently calculate or display runs. Done means all clients agree on next-run instants, the save flow previews local and UTC times, DST edge cases have deterministic tests, and timezone-less schedules remain compatible.

Written by the indexing model from the issue text.