parser: accept a LEADING parenthesized set-operation operand

[chiradip]

Summary

A statement could begin with a parenthesized query block only as the right-hand operand of a set operation. A leading ( at statement level — the canonical (SELECT 1) UNION (SELECT 2) — was never dispatched: parse_statement bailed out the moment it saw a token that was neither a keyword nor an identifier, so the whole statement failed to parse. This closes that gap.

Change

• Extract the set-operation fold out of parse_select_stmt into a member fold_set_operations(first_operand), and the trailing ORDER BY / LIMIT attach into attach_trailing_order_limit(target). This is a pure extraction — no change to precedence (INTERSECT binds tighter than UNION/EXCEPT/MINUS), left-associativity, ALL-modifier placement, or trailing-clause binding.
• Add parse_parenthesized_query() for a ( <query> ) operand, reused by both the RHS-operand path and the new leading path. It is DepthGuard-protected and recurses for nested ((...)).
• parse_statement now routes a leading ( through parse_parenthesized_query() then fold_set_operations(), so a leading parenthesized operand folds like any other and a trailing ORDER BY / LIMIT binds to the whole result.

Parentheses correctly override the INTERSECT-binds-tighter precedence: (A UNION B) INTERSECT C roots at INTERSECT with the UNION as its left operand — the opposite grouping from the unparenthesized A UNION B INTERSECT C.

Verification

• 5 new regression tests pin the AST shape for the leading-paren cases: both-paren, paren-left/bare-right, precedence override, nested + trailing ORDER BY, and lone-paren unwrap. Falsifiable — all 5 fail with the dispatch hook reverted and pass with it.
• Malformed / adversarial inputs reject gracefully (no crash); leftover-token leniency is identical to the unparenthesized forms (parity, not new laxness).
• 200k-deep ((((...)))) nesting is rejected via the DepthGuard — no stack overflow.
• Full parser suite 37/37; the precedence suite (21 tests) is clean under ASan/UBSan.

Scope

Top-level leading ( only. A leading ( after a WITH clause (WITH t AS (...) (SELECT 1) UNION (SELECT 2)) remains a separate, rarer follow-up.