parser: fold VALUES set-op inside parens + pin the whole VALUES/casing matrix

[chiradip]

Context

The last four audit passes each fixed one adjacent cell of the "VALUES as a set-op operand" neighborhood — VALUES on the RHS (#53), parenthesized-RHS ORDER BY (#56), bare top-level LEFT operand (#57) — a recurring fix-one-miss-the-neighbor pattern. Rather than wait for the next pass to surface the next cell, I exhaustively enumerated the whole neighborhood and found one still-broken cell.

Bug found & fixed

( VALUES (1) UNION SELECT 2 )   →   parse() returned NULL (whole query dropped)

parse_parenthesized_query dispatched a leading VALUES to parse_values_stmt() without folding a following set-op tail — unlike the SELECT branch (folds via parse_select_stmt) and the nested-( branch (fold_set_operations). So a set operation whose LEFT operand is a bare VALUES inside parens left the UNION … unconsumed, failing the ) check. Now it folds the tail there too, mirroring the sibling branches.

Guardrails (the main ask)

Two table-driven matrix tests pin the entire neighborhood, so a future change that drops any single cell fails loudly here instead of surviving to the next audit:

• ValuesSetOpOperandMatrix — 28 cells: VALUES standalone / LEFT / RIGHT / parenthesized / both-sides / chained / nested-in-parens / as an INTERSECT arm / with trailing ORDER BY/LIMIT / as a derived table.
• SetOpKeywordCasingMatrix — UNION/INTERSECT/EXCEPT × UPPER/lower/MiXeD (+ ALL).

Every cell asserts the root node type and that no operator/arm was dropped.

Full suite 37/37 green.