refactor: add internal Date adapter boundary

[gpbl]

DayPicker remains intentionally Date-based today, but the planned Temporal work needs an internal boundary between calendar logic and the concrete date implementation. Native Date assumptions are currently spread through calendar state, stable keys, comparisons, selection, and matcher logic. This change introduces that boundary while keeping react-day-picker instantiated with Date only.

What Changed

• Added an internal Date adapter boundary backed by the existing DateLib behavior.
• Routed internal date identity, stable key, timestamp, day-of-week, and comparison usage through that boundary where native Date assumptions were previously direct.
• Kept public Date APIs unchanged: no new accepted date type, no callback changes, no matcher contract changes, and no Temporal package or dependency.

Behavior Guarantees

• react-day-picker still instantiates the internals with native Date only.
• DateLib remains the source of truth for existing math, formatting, equality, and override behavior.
• TZDate remains Date-compatible and time keys remain equivalent to getTime().
• Package entry points and exported public types are unchanged.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 24c4927

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR