Support timezone in SDK temporal partition mappers

[Lee-W]

Why

The Core _BaseTemporalMapper accepts a timezone kwarg, but the SDK class Dag authors instantiate (from airflow.sdk import StartOfDayMapper) did not — and the _Serializer dispatch dropped _timezone even if it had. So StartOfDayMapper(timezone="Asia/Taipei") silently fell back to UTC after serialization.

What

• Add a keyword-only timezone kwarg to the SDK _BaseTemporalMapper.__init__, matching the Core signature.
• Normalise string timezone values via parse_timezone() at construction so unknown names raise pendulum.tz.exceptions.InvalidTimezone eagerly, and _timezone matches Core's type contract (Timezone | FixedTimezone) instead of staying as a str.
• Carry _timezone through the _Serializer dispatch handler for all six StartOf*Mapper classes so the Core class receives it on deserialize.
• Unify the StartOfHourMapper import in encoders.py so the singledispatch registration matches the runtime type used by Dag authors.
• Add a significant newsfragment documenting the keyword-only constructor as a breaking change against task-sdk/1.2.1.

Breaking changes

The SDK _BaseTemporalMapper constructor is now keyword-only. Callers that relied on StartOfDayMapper("%Y-%m-%dT%H:%M:%S") (valid in task-sdk 1.2.1) must switch to StartOfDayMapper(input_format="%Y-%m-%dT%H:%M:%S"). See airflow-core/newsfragments/67164.significant.rst.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: [Claude] following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[kaxil]

Adding *, here makes the SDK constructor keyword-only. That matches the Core class shape, which is the right destination, but it's a breaking signature change against the already-released task-sdk/1.2.1, where _BaseTemporalMapper.__init__ accepts input_format positionally — so StartOfDayMapper("%Y-%m-%dT%H:%M:%S") is valid public API today and would break on upgrade. Worth calling out in the PR description (and a newsfragment) since this is the public entry point Dag authors import via from airflow.sdk import StartOfDayMapper.

[Lee-W]

I just added it newsfragment and description. Should we include it in 3.3.0 or 3.2.3? interface inconsistency can probably(?) be considered as a bug.

[uranusjr]

One nit on timezone input handling in a thread above