chartTimeValue: DST transition hour can misplace/collide time-scale points (local-wall-clock parsing)

Problem

chartTimeValue (src/core/chart-data.ts, added in #309/PR for the Chart.js
time scale) parses a ClickHouse Date/DateTime/DateTime64 cell's literal
wall-clock digits into a Date via the local-timezone constructor
(new Date(year, month-1, day, hour, min, sec, ms)), with no timezone
awareness — a deliberate simplification mirroring the existing chartLabel()
display convention ("show it exactly as the server wrote it").

On a browser running in a timezone that observes DST, this is ambiguous/lossy
right at the transition hour:

• Fall-back (repeated hour): a wall-clock time like 01:30:00 occurs twice
  (once in each UTC offset). If a DateTime column has two distinct rows that
  both render as "2026-11-01 01:30:00" (or if ClickHouse's session/column
  timezone doesn't match the browser's and produces the same string for two
  real instants), chartTimeValue collapses them to the identical epoch — two
  points overlap on the time axis instead of sitting ~1 hour apart, which is
  exactly the "gaps show as gaps, no compression" guarantee the time scale
  exists to provide.
• Spring-forward (nonexistent hour): a wall-clock time like 02:30:00 on
  the spring-forward date doesn't exist locally; the JS Date constructor
  silently normalizes it to some other instant (engine-dependent) rather than
  rejecting it.

Why deferred

Proper handling needs real timezone-aware epoch computation (knowing the
ClickHouse column's/session's timezone, not just the browser's), which is a
materially bigger feature than #309's scope (a genuine Chart.js time scale for
line/area charts). The current behavior degrades gracefully — worst case is
one mis-plotted hour per year on hosts observing DST, never a crash — and
matches the pre-existing display convention exactly, so it isn't a regression,
just a narrow known limitation worth tracking.

Suggested acceptance criteria

• Decide whether to accept the current local-wall-clock behavior long-term
  (document it explicitly) or invest in timezone-aware parsing (needs a
  source for the relevant timezone — ClickHouse session timezone via
  system.settings/column type param, or a per-connection setting).
• If accepted as-is, add a one-line doc note next to chartTimeValue
  referencing this issue so a future reader doesn't rediscover the same
  ambiguity as a "bug."

Related

• #309 (Chart.js time scale for line/area charts — where chartTimeValue was added)

Start in src/core/chart-data.ts at chartTimeValue and review how the ClickHouse Date, DateTime, and DateTime64 literal values are converted for the Chart.js time scale. Decide whether to document the local-wall-clock limitation or pursue timezone-aware parsing; done means meeting one of the stated acceptance criteria and preserving the existing display convention.