CsvHelpers: validate MM/DD/YYYY dates in UTC

[arpitjain099]

isValidDate in src/validators/CsvHelpers.ts checks the parsed date with getUTCFullYear() / getUTCMonth() / getUTCDate(). That's right for the ISO YYYY-MM-DD branch, where date-only strings parse as UTC, but wrong for the MM/DD/YYYY (and M/D/YYYY) branch: the slash form parses in the local time zone and then gets read back with UTC getters.

In any positive UTC offset (a contributor in Asia/Tokyo, or a CI runner not pinned to UTC), local midnight lands on the previous calendar day in UTC, so the getters report the day before, the equality check fails, and a valid last_updated_on like 05/01/2024 is flagged as InvalidDateError. The repo's own tests show it: TZ=UTC npx vitest run passes, but TZ=Asia/Tokyo npx vitest run fails the MM/DD/YYYY and M/D/YYYY last_updated_on cases for v2.0.0, v2.1.0, and v2.2.0. The suite already encodes the right behavior and only passes because CI runs in UTC.

The fix builds the date in UTC from the components already parsed out of the string instead of re-parsing the raw value:

const parsedDate = new Date(Date.UTC(expectedYear, expectedMonth, expectedDate));

The impossible-date guard (Feb 31, month 13) still works since Date.UTC normalizes the same way and the equality check rejects them. The ISO branch is left alone, and I fixed the now-wrong comment that claimed the slash form parsed as UTC.

No new tests needed; the existing suite covers it, it just had to run outside UTC. After the change TZ=Asia/Tokyo, TZ=UTC, and TZ=America/Los_Angeles all pass 344/344, and prettier and eslint are clean on the file.