[6.x] Fix range date fields ignoring the configured timezone on save

[lazerg]

Fixes #14636. Supersedes #14984.

This replaces #14984, which took a backend approach that @jasonvarga correctly identified as a no-op on real saves: the Control Panel always submits an absolute UTC value, and Carbon::parse() ignores its timezone argument once the string carries an offset. He pinpointed the real cause in DateFieldtype.vue and offered to reopen, but the branch had been force-pushed with this rework and GitHub won't let the old PR reopen, so this is a fresh PR from the same branch.

Root cause

DateFieldtype.vue's datePickerUpdated() handles single dates and ranges differently. For a single date, the naive CalendarDateTime from the picker is first interpreted in the field's configured timezone before being converted to UTC:

if (!this.isRange && !value.offset && !value.timeZone) {
    value = toZoned(value, this.displayTimezone);
}
// ...
return this.update(toTimeZone(value, 'UTC').toAbsoluteString());

The range branch skipped that step and sent the naive start/end straight to UTC via toZoned(start, 'UTC'), so the field's wall-clock time was treated as if it were already UTC. Loading uses parseAbsolute(value, displayTimezone) (correct), so the load/save round-trip was asymmetric and the stored value drifted by the offset on every save.

Fix

Interpret the range's naive start/end in displayTimezone before converting to UTC, the same way single dates already do.

Test

Added a DateFieldtype.test.js case that drives datePickerUpdated() with the CalendarDateTime objects the picker actually emits (range + time mode, configured timezone). For a New York field, entering 05:00 now saves 09:00Z; it fails on the current code (which saves 05:00Z) and passes with the fix. Full unit suite green.

[jasonvarga]

Beautiful, thank you.