fix(proto): store far-future DateTime64 without int64 overflow

[dogacid]

Summary

proto.ToDateTime64 and DateTime64.Time convert a timestamp through an int64 nanosecond
count (t.UnixNano() on write, int64(d) * p.Scale() on read). That intermediate overflows int64
just past 2262-04-11 23:47:16 UTC, so any later timestamp is silently corrupted — on the way in
and out — even for precisions whose stored tick would fit int64 across a far wider range.

ClickHouse 26.7 extended the DateTime64 range (millisecond precision now stores up to
9999-12-31), so this is reachable in ordinary use. Concretely, writing an open-ended sentinel such
as 9999-12-31 23:59:59.999 into a DateTime64(3) column currently round-trips as 1900-… garbage.

Root cause

A DateTime64(P) value is stored as an int64 count of ticks of 10^-P seconds. The conversions
first scale the whole timestamp to nanoseconds:

// write
return DateTime64(t.UnixNano() / p.Scale())
// read
nsec := int64(d) * p.Scale()

t.UnixNano() (and the * p.Scale() on read) overflow int64 at ~2262 — even though the final tick
count at, say, millisecond precision would not overflow until roughly the year 292 million.

Fix

Compute at the column's own tick scale instead of via nanoseconds, so no oversized intermediate is
ever formed:

// write
secScale := int64(1e9) / p.Scale() // ticks per second (10^P)
return DateTime64(t.Unix()*secScale + int64(t.Nanosecond())/p.Scale())
// read
secScale := int64(1e9) / p.Scale()
return time.Unix(int64(d)/secScale, (int64(d)%secScale)*p.Scale())

• Identical result for all currently-working values — it is the same arithmetic, reordered so the
  intermediate never exceeds the tick magnitude.
• Each precision now reaches its true range — the same range ClickHouse's int64-tick
  DateTime64(P) supports. Coarser precisions reach much further; nanosecond precision (9) still
  caps near 2262, which is the genuine int64-nanosecond limit and matches ClickHouse's own
  DateTime64(9).
• The t.IsZero() short-circuit is preserved.

Tests

Adds TestDateTime64_FarFuture: round-trips the 2262 boundary, 2999, and the 9999-12-31 ceiling
across precisions 0/1/3/6/7, plus a millisecond-fraction case. These fail on main today
(e.g. 9999-12-31 → 1816-03-30) and pass with the fix. Existing tests are unchanged.

Notes

No measurable performance impact (a couple of extra integer operations; no allocation).