Naive datetime call filters use today’s UTC offset across DST seasons #29

The generated Python runtime serializes naive datetimes using today's local UTC offset rather than the offset on the datetime being serialized. calls.list(created_at_ge=datetime(2026, 1, 15, 12)) under TZ=America/Los_Angeles currently sends 2026-01-15T12:00:00-07:00 when the process runs during PDT. January should use -08:00, so the filter boundary shifts by one hour.

The shared serialize_datetime snapshots datetime.now().astimezone().tzinfo and then attaches that fixed offset with replace. Calling v.astimezone() on the naive value applies the local rules for that date, including fold=0/fold=1 during ambiguous fall-back hours. Explicitly aware inputs retain their existing serialization.

Offline reproduction: 56 cases through public sync/async calls.list and HTTPX MockTransport, covering four created/updated filters and winter/summer/fall-fold/aware/microsecond inputs. Before: 24 failed, 32 passed on macOS in October 2026. After the small runtime patch: 135 repository tests pass, 4 skipped (existing Pydantic deprecation warnings).

I have a tested proof-of-concept patch and will link it here. Per README, this generated-runtime fix needs porting into the Fern generation source before it can be merged durably. No live Vapi calls or voice resources used.