Don't count negative sign towards the integer digit limit

[lolopinto]

Negative JSON integers with exactly 4300 digits were rejected because the leading minus sign wasn't being counted towards the integer digit limit.

This changes it so that we count the digits independent of the sign and adds tests.

jiter.from_json(b"-" + b"9" * 4300)

This now parses successfully.

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/jiter/src/number_decoder.rs	87.50%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will degrade performance by 14.36%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 3 regressed benchmarks
✅ 67 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	massive_ints_array_jiter_iter	564.1 µs	688.5 µs	-18.06%
❌	massive_ints_array_jiter_value	743 µs	849.4 µs	-12.54%
❌	python_parse_massive_ints_array	1.1 ms	1.3 ms	-12.37%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing lolopinto:negative-integer-boundary (edc3e7b) with main (785cf75)}

[lolopinto]

@codspeedbot fix this regression

[lolopinto]

I pointed an agent at this and it made some changes and it thinks the rest is because we don't have an apples to apples comparison

[samuelcolvin]

looks like this damaged performance.

[lolopinto]

Looks like the regression is down to this:

• the base used num-bigint 0.4.6
• the PR resolved 0.4.8, which introduced a substantially slower allocation path for large integers.

The benchmark only contains positive integers, and testing with identical dependencies shows no meaningful performance regression from the PR itself.

Can we redo a base? or pin to 0.4.6?