fix: enforce max_string_length on JSON number lexemes

[cursor]

Bug and impact

After the std::from_chars number rewrite (#34), JSON number lexemes are buffered in m_number_token. Fractional digit runs appended to that buffer with no length cap, so a payload like 0. followed by a huge digit run could grow memory without bound and DoS the decoder. Integer overflow already self-limits near ~310 digits via non-finite rejection; fractions did not.

Root cause

#34 introduced lexeme buffering for correctly rounded parsing, but only strings (#24) and arrays (#25) were covered by existing DoS budgets. Number-token push_back paths (especially fractions) had no check against m_max_string_length.

Fix

Route all number-token appends through append_number_char(), which rejects when m_number_token.size() >= m_max_string_length (same overridable budget as strings).

Validation

• Added regression NumberLengthLimitAppliesToLexeme (tiny custom limit)
• ./tools/CB.sh debug test --tags='\[xson\]' — 434/434 passed

  

---

Note

Low Risk
Targeted parser hardening that reuses an existing limit; behavior change is rejecting oversized number lexemes that were previously a memory DoS vector.

Overview
Closes a DoS gap in the JSON decoder: after lexeme buffering for std::from_chars, long fractional runs (e.g. 0. plus many digits) could grow m_number_token without a cap, while integer-only overflow paths were already bounded.

All number-token appends now go through append_number_char(), which rejects when the lexeme reaches m_max_string_length (same overridable limit as strings). Regression test NumberLengthLimitAppliesToLexeme uses a tiny decoder limit for integers, fractions, and scientific forms.

^{Reviewed by Cursor Bugbot for commit 6f81e5a. Bugbot is set up for automated code reviews on this repo. Configure here.}