fix(parser): read && and || chains in a loop so a long chain cannot overflow the stack

[pdevito3]

Summary

 AndExprParser / OrExprParser
-  Parse.ChainOperator(op, operand, CombineClauses)   // one recursive call for each operator
+  ChainLeft(op, operand, CombineClauses)             // the same chain, read in a loop

 ParameterReplacer (runs when the configuration has property mappings)
-  ExpressionVisitor.VisitBinary                       // one recursive call for each level
+  VisitBinary: walk the left side of an AndAlso/OrElse chain in a loop, then rebuild it from the bottom

Precedence, left associativity, and the expression text do not change. a && b && c || d still gives ((a AndAlso b) AndAlso c) OrElse d. An operator with no operand after it still ends the chain before that operator, so Age > 1 && Age > 2 && throws the same ParsingException at the same column. The aliases (and, or, and custom operators) go through the same code.

v2 behavior (and main)

QueryKit used two recursive layers for a flat && or || chain. On a 256 KB thread, a chain of 212 clauses (about 2300 characters) overflowed the stack. A stack overflow stops the process, and a catch block cannot stop it.

New behavior

Flat Age > 1 && Age > 2 && ... chains, measured in a child process for each case. The value is the largest chain that does not overflow. The || results are the same.

Layer	Stack	Before	After
FilterParser.ParseFilter	256 KB	211 clauses (2317 chars)	more than 20000 (219996 chars)
	512 KB	424 (4660 chars)	more than 20000
	1 MB	849 (9335 chars)	more than 20000
ParseFilter with a HasQueryName mapping	256 KB	211	more than 20000
	512 KB	424	more than 20000
	1 MB	849	more than 20000
Compile(), and ApplyQueryKitFilter on IEnumerable	256 KB	211	2045 (22491 chars)
	512 KB	424	4093 (45019 chars)
	1 MB	849	8189 (90075 chars)
EF Core ApplyQueryKitFilter(...).ToQueryString()	256 KB	177 (1943 chars)	177 (1943 chars)
	512 KB	361 (3967 chars)	361 (3967 chars)
	1 MB	729 (8015 chars)	729 (8015 chars)

With only the parser change, the mapping row stopped at 3956, 8052, and 16244 clauses. The ParameterReplacer change removes that limit.

QueryKit no longer has a recursive layer for a flat chain. The limits that stay come from outside QueryKit:

• LambdaExpression.Compile (LambdaCompiler.EmitBranchOr) recurses once for each level.
• EF Core ExpressionTreeFuncletizer.VisitBinary recurses once for each level, and EF Core gets there before QueryKit returns.

A balanced tree can remove these limits too, but it changes the expression text. This PR keeps the left-nested tree.

Parse time also gets shorter. On a 64 MB stack, 20000 clauses took 8.5 s before and 3.5 s after. Parse time still grows faster than the clause count.

MaxInputLength

Do not raise the default of 5000 from #135 because of this PR. EF Core overflows at 3967 characters on a 512 KB stack and at 8015 characters on a 1 MB stack, before and after this PR. On a 256 KB stack it overflows at 1943 characters, which is less than the current default. The parser is now not the limit, so a higher default only helps apps that use IEnumerable or that run on a large stack. This PR does not change the default.

The arithmetic operators (+, -, *, /, %) also use Parse.ChainOperator. A long arithmetic chain can still overflow in the parser. A later PR can give them the same loop.

Evidence

• Before: the new small-stack tests stopped the test host: The active test run was aborted. Reason: Test host process crashed : Stack overflow. With only the parser change, the mapping test crashed the host the same way.
• After: 474 unit tests and 298 Postgres integration tests (Testcontainers) pass, 0 failures.

qk run (verify-querykit harness, memory and Postgres targets, default configuration on v2):

Clauses	Characters	Result
100	1396	4 rows on both targets
357	4994	4 rows on both targets, && and `
358	5008	QueryKitInputLengthExceededException on both targets

On main without a length limit, the same harness stopped with Stack overflow. (exit 134) at 5000 clauses, in EF Core ExpressionTreeFuncletizer.VisitBinary.

Tests

ParseLimitsTests:

• long_flat_chain_parses_on_a_small_stack (&& and ||): 20000 clauses on a 256 KB thread.
• long_flat_chain_with_aliases_and_a_query_name_parses_on_a_small_stack: 20000 clauses with the and alias and HasQueryName("age") on a 256 KB thread. It compiles the first and the last clause with the lambda parameter, which shows that the visitor replaced the parameter in the whole chain.
• flat_chain_keeps_and_before_or_and_groups_from_the_left: pins the expression text of a mixed chain.
• flat_chain_that_ends_with_an_operator_throws_a_parsing_exception: pins the error column.

Three CS8603 warnings in the test projects are also corrected, so the build has 0 warnings.

Merge Danger

Door: two-way

The public API, the grammar, and the expression text do not change. A revert puts the recursion back.

Blast Radius: parser

Every filter with && or || goes through ChainLeft. All existing filter tests pass on both targets.