Bound input size in validate_expression_tool / validate_style_tool to prevent heap OOM

[mattpodwysocki]

Summary

Follow-up to #125, addressing review feedback from @Valiunia about unbounded recursion in the new style-spec-delegating validators.

The depth cap added in #125 only protects against deep adversarial input (a long linear chain). It does not protect against wide-but-shallow input - e.g. a single match expression with millions of branches, at depth ~1 - which sails past the cap untouched and gets handed whole to createPropertyExpression/validate().

	Deep (stack overflow)	Wide (heap OOM)
Triggered by	linear nesting depth	total array/object size
Caught by our try/catch?	Yes - RangeError is a normal JS exception	No - V8 aborts the process before JS code can run
Blast radius	that one request fails	entire process dies, killing every concurrent MCP session
Stopped by the #125 depth-64 cap?	Yes	No - depth never exceeds ~1
Stopped by this PR?	Yes (already, via #125)	Yes

Reproduced the wide case under a memory-constrained process (node --max-old-space-size=150) and confirmed it's worse than the stack-overflow case: heap exhaustion is not a catchable JS exception - V8 aborts the process directly (FATAL ERROR: Reached heap limit, SIGABRT), which would take down every concurrent MCP session, not just the one request.

Fixed with two layers of defense:

• Schema-level size caps on the JSON-string form of expression (256 KB) and style (10 MB) in their Zod schemas, rejected before JSON.parse ever runs. Note: for validate_expression_tool, z.union([z.string().max(N), z.any()]) does not work, since the sibling z.any() branch matches everything, including oversized strings, and swallows them right past the length check - had to use a .refine() instead.
• O(1) array-length / object-key-count guard, checked via .length before ever iterating into or copying the collection, alongside the existing depth guard. This covers the already-parsed object-input path too (not just JSON strings), and rejects an oversized array/object anywhere in the tree without visiting its elements.

Test plan

• npm test - all 596 tests pass, including new regression tests for both the wide-payload and oversized-string cases in both tools (asserting fast rejection, not just non-crash)
• npm run lint - 0 errors
• npm run build - succeeds
• Manually reproduced the OOM crash pre-fix (node --max-old-space-size=150 + a 2,000,000-branch match expression → SIGABRT/FATAL ERROR: Reached heap limit) and confirmed post-fix it's rejected in ~1ms with a clear error instead

🤖 Generated with Claude Code