fix(tz): reset fold to 0 for unambiguous local times

[saadkhantareen]

Summary

Fixes #853.

Datetimes created for ordinary, unambiguous local times reported a bogus fold value of 1, and the value changed inconsistently depending on the operation performed:

>>> dt = pendulum.datetime(2024, 5, 1, tz="CET")
>>> dt.fold
1
>>> dt.add(minutes=1).fold
0
>>> dt.add(days=1).fold
1

Per PEP 495, fold must be 0 for local times that are not ambiguous.

Changes

• Timezone.convert(): after normalizing a naive datetime, reset fold to 0 when the resulting local time is not ambiguous (its UTC offset is the same for fold=0 and fold=1). Ambiguous times keep the fold they were resolved with, so the existing default of resolving repeated times to their second occurrence is unchanged, as is the fold-based resolution of skipped times.
• DateTime.set(): only carry the current fold over to the new time when the current time is actually ambiguous. Otherwise the meaningless fold of an unambiguous time decided how a new time falling in a DST gap or overlap was resolved; the default resolution of DateTime.create() now applies, which preserves the existing behavior of fluent setters such as at() around transitions.
• Added regression tests covering Timezone.convert(), pendulum.datetime() with add(), ambiguous times keeping their fold, and set() on an ambiguous time.

Tests

$ PENDULUM_EXTENSIONS=0 python -m pytest tests/tz/test_timezone.py tests/datetime/test_fluent_setters.py -q
117 passed, 2 skipped

$ PENDULUM_EXTENSIONS=0 python -m pytest tests/ -q
1875 passed, 3 skipped

Pull Request Check List

• Added tests for changed code.
• Updated documentation for changed code.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.