Fix checked parsing for argument and JSON depth limits

[AnnoyingTechnology]

I have excess 5.6-sol and Fable 5 credits, and decided to use them to contribute back to OSS that I depend upon.

gpt5.6-sol cross-checked by Opus 4.8. Fable 5 could not cross-check due to safeties being triggered.

what

• Parse SecArgumentsLimit through its existing checked
  ConfigUnsignedInt wrapper.
• Do the same for SecRequestBodyJsonDepthLimit.
• Return directive-specific configuration errors for values outside the
  wrapper's range.
• Add regressions for the uint32_t maximum, 2^32, and decimals wider than
  uint64_t.
• Register the new regression fixture in the standard make check suite.

why

PR #3421 converted these fields to checked unsigned wrappers so out-of-range
configuration would fail during startup, but these two grammar productions
still assigned atoi(...) directly.

On the tested platform, 4294967296 wrapped to zero. A zero
SecArgumentsLimit skipped every request argument, while a zero
SecRequestBodyJsonDepthLimit prevented the top-level JSON argument from being
exposed. The new code uses the same checked parsing pattern as the adjacent
body, PCRE, and upload limits.

This is configuration validation for trusted directives, not a remotely
triggerable vulnerability claim.

validation

• New regression: 6 passed, 0 failed.
• Existing SecArgumentsLimit regression: 2 passed, 0 failed.
• Existing JSON parser regression: 6 passed, 0 failed.
• Full make check: 5,049 total; 4,997 passed; 52 skipped; 0 failed.
• git diff --check: pass.
• Test JSON parsed with jq: pass.

Base: v3/master at
7ea9fefbe0ba409d8733b4d682c8c4c059cd028d.

references

• Completes the checked-wrapper migration from fix: integer type limits, 2nd try #3421 for the two grammar
  productions that still assigned atoi(...) directly.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud