fix: preserve large integer precision in JSON Beautify

[mkilijanek]

Summary

Fix JSON Beautify so large integer literals keep their original precision instead of being rounded during parsing.

Existing Issues

Closes #415

Root Cause

JSON Beautify parses input with JSON5.parse() and then serializes it with JSON.stringify(). Large integers outside JavaScript's safe integer range are coerced to imprecise number values during parsing.

Changes

• protect unsafe integer literals with sentinels before parsing
• restore those literals in formatted JSON output
• render protected literals as numbers in the HTML presenter
• add a regression test for 1234567890123456789

Validation

• npm run lint
• direct smoke on upstream-based branch confirms JSON Beautify now preserves 1234567890123456789
• full upstream npm test could not be completed locally under Node 22 because upstream master still uses import ... assert { type: "json" } syntax and runs with older module flags; this failure is pre-existing baseline behavior in my local runtime, not introduced by this patch

[CLAassistant]

All committers have signed the CLA.

[C85297]

Hi @mkilijanek , thank you for your pull request.
I'd like to hear more about the issue that is behind this pull request, if possible?

In the absence of a particular issue, I'm not sure that we need to handle such large numbers in the JSON Beautify operation. The operation is not intended to perform or prepare for processing of the contents of the JSON, but rather to render it in a format that is easier for humans to read.
Although it would be preferable to accurately render the JSON, given that the JSON specification (RFC 7159) allows implementations to limit the range of numbers that it can handle, I would think it acceptable for us to imperfectly render extremely large numbers.

This pull request would not be zero cost - it adds a large amount of code we would need to maintain, and the approach of scanning the JSON input with regexes and building an output string character by character would be costly with large inputs.

Given all of this, I'd like to understand more about your use case that requires handling of big numbers by JSON beautify, so that we can weigh up the cost/benefits.

[mkilijanek]

Hi @mkilijanek , thank you for your pull request. I'd like to hear more about the issue that is behind this pull request, if possible?

In the absence of a particular issue, I'm not sure that we need to handle such large numbers in the JSON Beautify operation. The operation is not intended to perform or prepare for processing of the contents of the JSON, but rather to render it in a format that is easier for humans to read. Although it would be preferable to accurately render the JSON, given that the JSON specification (RFC 7159) allows implementations to limit the range of numbers that it can handle, I would think it acceptable for us to imperfectly render extremely large numbers.

This pull request would not be zero cost - it adds a large amount of code we would need to maintain, and the approach of scanning the JSON input with regexes and building an output string character by character would be costly with large inputs.

Given all of this, I'd like to understand more about your use case that requires handling of big numbers by JSON beautify, so that we can weigh up the cost/benefits.

Thanks, that is a fair concern.

My rationale was that "JSON Beautify" looks like a presentation-only operation, so users may reasonably expect it not to alter literal values. Large integers often appear in practice as IDs, counters, timestamps, or other opaque values, and rounding them during beautification can be misleading during analysis.

I do agree the current fix has a non-trivial maintenance cost. If that tradeoff is not worth it for this operation, I am happy either to rework it into a narrower solution or to leave this as a documented limitation instead.