The C accelerator of json reported Invalid \uXXXX escape where the pure-Python decoder reported Unterminated string starting at, for a \uXXXX escape whose final hex digit is the last character of the input. The two decoders disagreed on the error class, and the C one pointed the user at a non-existent invalid escape rather than the missing closing quote.

Root cause in Modules/_json.c scanstring_unicode(): the bounds check used >= where > is correct. The four hex digits are read at indices end-4 .. end-1; when end == len those are all in bounds, so the escape is complete and valid and the string is merely unterminated. Changing >= to > lets control fall through to the existing Unterminated string starting at path, matching the pure-Python decoder (the two json error messages were synchronized in bpo-5067).

Tests cover both decoders: test_fail.py::test_truncated_input asserts the exact message/position under TestCFail and TestPyFail (including a high surrogate and a surrogate pair at EOF, and a nested non-zero offset), and test_scanstring.py::test_bad_escapes gains two no-regression cases (a genuinely truncated escape and four non-hex chars at EOF) confirming the change does not weaken rejection of real invalid escapes.

Fixes #152052

• Issue: json: C decoder reports "Invalid \uXXXX escape" instead of "Unterminated string starting at" for a complete \uXXXX escape at end of input #152052