fix year overflow on leap-second carry in ParseCivilTime

[dxbjavid]

ParseCivilTime parses the year on its own, normalises it into a small range around 2400 so the rest of the string can go through ParseTime, then rebuilds the result by adding the field-normalisation carry back onto the original year. The carry itself is small, but the year it is added to comes straight from the input, and at the largest representable year a trailing leap second rolls the value one past the maximum, so the addition overflows civil_year_t. It is reachable from untrusted text because the civil-time types parse flag and configuration strings through this path, and a value like 9223372036854775807-12-31T23:59:60 triggers it: a sanitiser build reports signed integer overflow at the carry, while an ordinary build silently wraps the year to the minimum and still returns success. I came across it while reading the carry handling that was added recently. Bounding the addition against the type limits and failing the parse when it would overflow leaves every normal year untouched and only rejects the few values that cannot be represented. I have added a regression case beside the existing carry test.