pytime_from_double() in Python/pytime.c converts a float number of
seconds to a PyTime_t (nanoseconds). On overflow it called
pytime_time_t_overflow(), which reports "timestamp out of range for platform time_t" — but this path never converts to time_t. The integer
path, pytime_from_object(), already reports the same conceptual overflow
with pytime_overflow() ("timestamp too large to convert to C PyTime_t").

This swaps the float path to pytime_overflow() so both paths agree and the
message names the type actually involved. The old wording was wrong in fact,
not only in type: PyTime_t saturates at roughly 292 years (int64
nanoseconds), while 64-bit time_t spans far longer, so e.g.
time.sleep(1e10) (~317 years) overflows PyTime_t yet is well within
time_t range — the reported time_t limit was never the actual constraint.
The correct helper already exists in the same file, so this is a one-line
change that only affects the message text; it targets main only.

User-visible via any float-seconds API, e.g.:

>>> time.sleep(2.0 ** 63)   # before: "... platform time_t"; after: "... C PyTime_t"

Verified in a build of main: the _PyTime_FromSecondsObject() float path
(and time.sleep()) now raises the PyTime_t message for both positive and
negative out-of-range values, matching the integer path; the full
test_time suite passes. A regression test asserting the float-path overflow
message is added to TestCPyTime (fails before the fix, passes after).

• Issue: Misleading time_t overflow message for out-of-range float timestamps in pytime_from_double() #152849