fix(bigquery): align DATE() function output to TIMESTAMP for SQL API compatibility

[tlangton3]

Summary

Fixes #10643. When querying via the SQL API (Postgres wire protocol), CAST(x AS DATE) = DATE('2024-01-08') generates TIMESTAMP = DATE on BigQuery, which BigQuery rejects. This pattern originates from Tableau connecting via the SQL API.

Changes

• Override the functions/DATE template for BigQuery to produce TIMESTAMP(args) instead of DATE(args), aligning the SQL output with the date UDF's declared Timestamp return type in CubeSQL
• Add TIMESTAMP cast for time dimension filter parameters in BigqueryFilter.castParameter()
• Add two integration tests covering both the MEASURE() (Cube REST API) and COUNT() (SQL push-down) code paths

Implementation Details

The CubeSQL date UDF declares its return type as Timestamp for compatibility with the egg rewrite engine's time dimension filter patterns. However, the functions/DATE SQL template in BaseQuery.js renders as DATE(args) which produces a DATE type in BigQuery. When plan_normalize coerces the other side of a comparison to match the Timestamp return type, the generated SQL becomes TIMESTAMP = DATE — which BigQuery rejects.

The fix overrides the DATE function template for BigQuery to produce TIMESTAMP(args). This is safe because the hardcoded DATE() calls in time series templates (e.g., GENERATE_DATE_ARRAY(DATE(...))) are inline strings within those templates, not calls to the functions/DATE template.

The castParameter fix is an additional safety net ensuring time dimension filter parameters are explicitly cast to TIMESTAMP when using the standard filter code path.

Testing

• All 699 CubeSQL Rust unit tests pass (no Rust changes required)
• BigQuery integration tests with Tesseract ON: 96 passed, 2 failed (pre-existing), 38 skipped — no regressions
• Two new integration tests verify both MEASURE() and COUNT() paths with CAST(x AS DATE) = DATE('...')

Linear Ticket

N/A