Fix Polars temporal column stats JSON serialization for tracker

[dgvj-work]

Make Polars Date/Datetime column stats JSON-safe for the tracker, and keep Time/Duration off the datetime UI path.

Changes

• Keep Date/Datetime on datetime_column_stats with ISO timestamps (base_data_type="datetime")
• Route Time/Duration to unhandled stats so the UI does not try to parse "01:00:00" / "1 day, 0:00:00" as Dates
• Add a Datetime Series regression test matching Hamilton tracker gives an error with datetime columns in polars dataframes #1127, plus coverage that Time/Duration stay unhandled

How I tested this

• pytest ui/sdk/tests/tracking/test_polars_col_stats.py ui/sdk/tests/tracking/test_polars_stats.py (22 passed)
• ruff format on the touched files (passed)

Notes

• On main, temporal columns already avoid the original std() crash by routing through datetime_column_stats with std=0.0, but Hamilton tracker gives an error with datetime columns in polars dataframes #1127 was still open: there was no regression test pinning that Datetime path. This PR closes that loop without sending Time/Duration through the datetime renderer.

Closes #1127

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[jernejfrank]

Hey, just a small thing since not everything renders on UI

[jernejfrank]

This breaks a couple of daterendering on the UI:

"2021-01-01T00:00:00" → valid Date
  "01:00:00"             → Invalid Date / NaN
  "1 day, 0:00:00"       → Invalid Date / NaN
  "2 days, 0:00:00"      → Invalid Date / NaN

Can we route Time/Duration to unhandled stats for now?

[dgvj-work]

@jernejfrank Good catch, those Time/Duration strings are not valid JS Dates, so they were breaking the datetime range renderer.

I routed Time and Duration to unhandled stats instead of datetime stats. Date/Datetime still go through the datetime path with ISO timestamps (2021-01-01T00:00:00), which new Date(...) can parse.

The #1127 Datetime regression coverage is still there, plus a test that Time/Duration stay on the unhandled path (no min/max date strings).