fix unbounded recursion in the script expression parser

[aysha-afrah26]

The scripting engine compiles precondition, postcondition, and <Script> attributes into an AST with a hand-written recursive-descent Pratt parser, where every open parenthesis, unary prefix (-, !, ~), and right-hand operand adds one parseExpr frame. Nothing bounds that recursion, so a script value that is a long run of ( or ! recurses once per character until the native stack is exhausted and the process dies with a SIGSEGV. Those strings come straight from XML attributes and are compiled at tree build and validate time, before any node ticks, so a single crafted tree crashes the executor while it is still loading (a ~30 KB nested script is enough on a default 8 MB stack, and less on Windows). I noticed it because the XML parser already guards against this exact shape with kMaxNestingDepth in VerifyXML and recursivelyCreateSubtree, while the script parser those paths feed had no equivalent limit. The fix caps the nesting depth inside parseExpr and throws a regular parse error once the limit is passed, matching the XML cap. Ordinary scripts are unaffected: long flat expressions and chained comparisons are parsed iteratively, so only genuinely deep nesting trips the limit, and the added test covers both the rejection and that normal scripts still parse.