Fix boolean() parsing for comparisons between inline condition expressions

[Copilot]

boolean((@foo = 1) = (@bar = a)) was being misparsed, which surfaced as an undefined variable error even though the assignment existed. The parser handled precomputed boolean vars correctly but failed when equivalent condition expressions were inlined.

• Parser: allow condition-to-condition equality in custom condition contexts

  • Updated condition parsing in packages/less/lib/less/parser/parser.js so custom condition consumers (boolean(...), if(...)) can parse comparisons where operands are themselves condition expressions (including parenthesized forms).
  • Scoped this behavior to the relevant condition path to avoid altering unrelated query/media parsing behavior.

• Regression coverage

  • Added a focused case in packages/test-data/tests-unit/functions/functions.less:
    • f: boolean((2 > 1) = (3 > 2));
  • Updated expected output in packages/test-data/tests-unit/functions/functions.css:
    • f: true;

• Behavioral example

  @foo: 1;
  @bar: a;
  @is-baz: boolean((@foo = 1) = (@bar = a));
  
  :root {
    --baz: @is-baz; // true
  }

[greptile-apps]

Greptile Summary

This PR allows condition results to be compared inside Less boolean functions. The main changes are:

• Adds an opt-in parser mode for condition operands in boolean() and if().
• Propagates the mode through nested and negated conditions.
• Adds a test for equality between parenthesized comparisons.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• Existing guard and media-query callers keep their previous parsing behavior.
• The new parsing branches preserve the original condition when no outer comparison follows.

_{Reviews (1): Last reviewed commit: "Fix boolean comparison of inline conditi..." | Re-trigger Greptile}