fix: skip native Date fast path when local timezone is overridden via setLocalTimeZone

[apoorvdarshan]

Summary

• Fixes setLocalTimeZone if used and different from the browser time zone, causes date time conversion to be incorrect when converting the local timezone #9669 — setLocalTimeZone causes incorrect timezone conversion when the overridden timezone differs from the browser's timezone
• Skips the native Date fast paths in getTimeZoneOffset and toAbsolute when setLocalTimeZone has been called, falling back to the correct Intl.DateTimeFormat-based computation
• Adds a localTimeZoneOverride flag in queries.ts that tracks whether setLocalTimeZone has been called (and is cleared by resetLocalTimeZone)

Test plan

• Added 3 new tests in conversion.test.js covering:
  • getTimeZoneOffset returns correct offset when local timezone is overridden
  • toAbsolute returns correct result when local timezone is overridden
  • resetLocalTimeZone restores the native Date fast path
• All 372 existing tests in @internationalized/date continue to pass

[LFDanLu]

Thank you for the PR! I think the code changes and tests look good, but it seems @sonsu-lee has also submitted a PR with similar changes. I'll leave it to you two to decide how yall want to proceed from here since these came in at roughly the same time haha.

As an aside, I'd would like the queries tests from #9680 to also make it in just for completeness.

[apoorvdarshan]

Thanks for the review @LFDanLu! I've pushed updates addressing your feedback:

• Fixed the lint import ordering issue (alphabetical sort)
• Added the isLocalTimeZoneOverridden queries tests from fix: skip native Date fast paths when local timezone is overridden (#9669) #9680 for completeness
• Exported isLocalTimeZoneOverridden from the public index

Regarding @sonsu-lee's PR #9680 — it looks like we both arrived at the same solution independently, which is great validation of the approach! I submitted this one ~30 minutes earlier, but happy to defer to whatever you and the team prefer. If there's anything from #9680 you'd like incorporated here that I'm still missing, just let me know.

[sonsu-lee]

Thanks for the review @LFDanLu. Funny that @apoorvdarshan and I ended up with basically the same fix. #9678 was first and already has your feedback addressed, so I'll close this one. Nice work @apoorvdarshan!

[apoorvdarshan]

Thanks @sonsu-lee, appreciate the kind words and for closing yours in favor of this one! Great minds think alike 😄

@LFDanLu all feedback has been addressed and CI is green now — let me know if there's anything else needed.

[LFDanLu]

Looks good to me, thank you @apoorvdarshan and @sonsu-lee both! I'll see about getting another pair of eyes on this