Enforce maxNameLength incrementally in ReaderBasedJsonParser [GHSA-649p-m576-vr99]

[tinyb0y]

Fixes GHSA-649p-m576-vr99.

ReaderBasedJsonParser._parseName2() only validated accumulated
property-name length against maxStringLength while buffering, and
against maxNameLength once at the very end (via findSymbol).
Reader/String/char[] input could therefore buffer a property name up
to maxStringLength before maxNameLength ever fired, unlike
byte-based input, which already validates incrementally via
ParserBase._growNameDecodeBuffer().

This tracks accumulated length locally in _parseName2() and
validates on each buffer-segment fill, matching the existing
byte-parser idiom (same pattern as #1611 for the analogous
maxNumberLength async-parser gap).

Tests

• New LargeNameReadTest.largeNameWithSmallLimitCharsFailsFast pins
  the fix: fails on unpatched code (reports the full buffered length),
  passes on patched code (rejects within one buffer-segment fill).
• Full mvn test: 1441 tests run, 0 failures, 0 errors, 2 skipped
  (pre-existing).

[cowtowncoder]

@tinyb0y Sounds good, I will review.

One last (?) thing, if not done already (apologies if I missed it, if so just LMK): we need CLA:

https://github.com/FasterXML/jackson/blob/main/CLA-jackson-2026.pdf

which is usually done by printing, filling/signing, scan/photo, email to cla at fasterxml dot com.
Only needed once; once we have it can merge any and all PRs.

Looking forward to merging!

[tinyb0y]

@cowtowncoder I've shared the signed CLA via email.

[cowtowncoder]

Wow that was fast, @tinyb0y ! Thank you.