encode whole-second datetime timestamps as integers across full range

[sahvx655-wq]

Changes

Under datetime_as_timestamp, encode_datetime decides whether a value can be written as an integer by narrowing the POSIX timestamp through a u32 and comparing it back against the float. That cast saturates: anything negative collapses to 0 and anything past 2106-02-07 collapses to u32::MAX, so the equality check never holds for a whole-second datetime before 1970 or after 2106. Those values still round-trip, but they go out as a tag 1 float64 rather than the compact integer the original pure-Python encoder always produced for whole-second timestamps. I spotted it while diffing the Rust output against the historical implementation, where datetime(1969, 12, 31, tzinfo=utc) came back as c1fb... instead of a negint.

Widening the cast to i64 restores the integer path across the whole representable datetime range, negative timestamps included, while the existing timestamp_int as f64 == timestamp_float guard still falls back to a float when there are sub-second microseconds. The decision belongs here in the encoder because it is what shapes the wire form. Left as is it emits non-canonical, larger output and silently disagrees with every other cbor2 release for any timestamp outside a 136-year window.

Checklist

• You've added tests (in tests/) which would fail without your patch
• You've updated the documentation (in docs/), in case of behavior changes or new features
• You've added a new changelog entry (in docs/versionhistory.rst).

[coveralls]

coverage: 94.659%. remained the same — sahvx655-wq:datetime-timestamp-i64 into agronholm:master

[agronholm]

Looks good, thanks!