fix(web): correctly display asset dates in historical timezones

[compscitwilight]

Description

Fixes an issue where editing and displaying asset dates in timezones with historical offset changes could result in an incorrect local time being shown in the web UI.

Additionally, I've addressed a subtle UI desync issue when editing datetime values for assets. When you edit an asset's timestamp via the modal, it will now reflect the same changed value inside of the detail panel as well.

Fixes #29364

How Has This Been Tested?

• Manually tested editing the date and time of an asset using America/Indiana/Vincennes
• Verified that setting an asset to March 15, 1990 at 3:58PM preserves the entered local time
• Verified that the resulting timestamp is correctly shown using the historical timezone offset
• Verified that changing only the time or date + both the date and time shows the correct date/time

Screenshots (if appropriate)

Checklist:

• I have carefully read CONTRIBUTING.md
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

Please describe to which degree, if any, an LLM was used in creating this pull request.

Used an LLM to assist with understanding the existing date handling code and investigating the interaction between timezone conversions and Svelte code. I performed the implementation and code changes myself.

[immich-push-o-matic]

Label error. Requires exactly 1 of: changelog:.*. Found: 🖥️web. A maintainer will add the required label.

[danieldietzler]

I am unsure if this even fixes anything, or if this has already been resolved in v3. Let's wait until we get confirmation on the issue before considering this PR