Validate number_mode in load and Decoder - #244

Summary

load() and Decoder() accept number_mode=1.0 without an error, and their int conversion can accept out-of-range integers on Linux. Reuse the existing validator used by loads() to reject these inputs before decoding, with 102 regression cases covering all six decoding routes, constructor-only rejection and stream preservation.

load(...):    accept_number_mode_arg(mode, allow_nan, number_mode)
Decoder(...): accept_number_mode_arg(mode, -1, number_mode)

Evidence

• On the unchanged base, the new cases report 33 failures on Windows and 51 on Linux; all 102 pass with the fix.
• pytest tests: 1,033 passed, 17 skipped and two expected failures on Windows Python 3.13 and Linux Python 3.13, 3.14 and 3.15.0rc3. Linux Python 3.10 reports 1,039 passed with the same skips and expected failures.
• The documented doctest check passes all 274 examples on Windows and Linux Python 3.13. stubtest rapidjson passes on Windows Python 3.13 and Linux Python 3.13, 3.14 and 3.15.0rc3.

Merge danger

Door: two-way. Blast radius: parser options.

Invalid types now raise TypeError, and oversized integers raise ValueError. For load() and Decoder(), the invalid-integer message changes from Invalid number_mode to Invalid number_mode, out of range; callers matching the old exact text would need to adjust. The existing unsupported NM_NATIVE | NM_DECIMAL error text is retained.

Unverified

Hosted CI, debug Python, macOS, other wheel architectures, stable Python 3.15, sanitisers and benchmarks are unverified. Python 3.10 doctests/stubtest and Python 3.15rc3 doctests were not run; the current full test requirements require a newer Python than 3.10. Paired Python 3.14 doctest runs have the same single native-integer representation failure on the unchanged base and candidate. Its cause is unverified. Stale Python 3.9 tox checks were not run because the package requires Python 3.10+. No lint command is configured.