Oversized datetime, UUID and parse modes are accepted after integer narrowing #247

Oversized mode integers are accepted after narrowing to C int

On Linux x86-64 (LP64), oversized datetime_mode, uuid_mode and parse_mode integers can be accepted as valid flags. For example:

import io
import rapidjson

rapidjson.load(io.StringIO('null'), uuid_mode=2**32)  # returns None
rapidjson.Decoder(parse_mode=-(2**32))('null')        # returns None
rapidjson.dumps(None, datetime_mode=2**32 + 1)       # returns 'null'

I expected these values to be rejected as out of range. For comparison, loads('null', uuid_mode=2**32) already raises ValueError.

Reproduced with release 1.25 and a separately compiled current master, fcf6dd6, on Linux Python 3.12.15. The issue is platform dependent: the corresponding current-source tests already reject these values on Windows, where C long is 32 bits.

load() and Decoder() assign PyLong_AsLong() to an int before checking the datetime/UUID/parse ranges. The shared valid_datetime_mode(int) also narrows a long supplied by other entry points. Values such as 2**32 and -(2**32) consequently become zero before validation on LP64. Keeping long until validation avoids this without changing valid flags or existing error messages. This is distinct from the number_mode correction in #244.

I found this during a source review with AI assistance, rather than in a production application. Tests and a focused fix are prepared. Existing string, binary-stream and text-stream fixtures reproduce 66 failures out of 90 new cases against current Linux source; all 90 pass with the fix.