Visit pipe expressions through shared deparser paths

[minleejae]

A custom ExpressionDeParser can rewrite SELECT 7 while leaving FROM t |> SELECT 7, |> SET a = 7 and |> LIMIT 7 unchanged. These pipe operators append nested AST nodes directly, bypassing the supplied expression visitor. This makes transformations inconsistent across equivalent ordinary and pipe SQL.

Route SELECT and EXTEND items through the existing select-item visitor, reuse the ordinary UPDATE assignment deparser for SET, and visit LIMIT/OFFSET expressions explicitly. This removes duplicate assignment rendering while preserving aliases, tuple brackets and default SQL output.

The downstream investigation found Confluent JDBC's custom deparser overrides explaining why nested expressions must remain reachable through visitors. The pipe cases here are independent upstream reproductions; they are not a claim about Confluent using pipe syntax.

Tests exercise one custom printer across a pipeline, check that each literal is visited once, preserve aliases and the original AST, and round-trip DISTINCT, EXTEND, subqueries, tuple assignments and LIMIT/OFFSET.

Validation: Java 17 ./gradlew --console=plain --max-workers=2 check, including all tests and static analysis.