TIME columns are never cast: needs_cast ignores a Time64 unit mismatch

Summary

ggsql's Time convention is nanoseconds — casting.rs targets Time64(Nanosecond) and schema.rs reads through the strict as_time64_ns — but needs_cast (src/plot/scale/scale_type/mod.rs:2205) treats any (Time64(_), Time64(_)) pair as already being the target type, so DuckDB's native Time64(Microsecond) is never converted.

Reproduction

SELECT * FROM (VALUES (TIME '08:00:00', 1), (TIME '12:30:00', 4), (TIME '18:15:00', 2)) AS t(tm, v)
VISUALISE tm AS x, v AS y
DRAW point

Failed to generate Vega-Lite output: Internal error: Expected Time64(Nanosecond) array, got Time64(Microsecond)

The hephaestus writer does not error — it renders raw microsecond values against a domain ggsql could not resolve, which is worse.

Suggested fix

Treat a unit mismatch as needing a cast: (Time64(a), Time64(b)) is already-target only when a == b. The neighbouring (Timestamp(_, _), Timestamp(_, _)) arm has the same wildcard shape and should be audited at the same time.

Start at src/plot/scale/scale_type/mod.rs:2205 and inspect the needs_cast logic for Time64 unit pairs. Run the SQL reproduction from the issue, then verify that mismatched time units are converted to the convention used by casting.rs and accepted by schema.rs. Audit the neighboring Timestamp arm as requested and confirm the reproduction produces Vega-Lite output without the Time64 error.