fix(tesseract): multi_stage reduce_by no-ops on type:time dimensions

[tlangton3]

Summary

multi_stage: true measures (rank, window aggregates) configured with reduce_by: [<time_dim>] silently produce wrong results when the consumer query specifies a granularity — every row reports rank() = 1 (or, for sums, the per-row value rather than the cross-time aggregate). Because the emitted SQL is well-formed, the bug bypasses validation and surfaces only as broken BI dashboards (a "rank by gross profit across all days for this district" tile showing every district at rank 1).

The workaround is to query the time dimension without an explicit granularity — sidestepping the suffix mismatch entirely. That constrains every consumer to query at the raw timestamp grain, eliminating natural day/week/month groupings on the time dim that's being reduced by, which is a real loss of expressiveness.

Root cause is a string-equality mismatch in has_member_in_reference_chain: the projected time dim resolves as a TimeDimensionSymbol whose full_name carries a granularity suffix (_day/_month/etc., defaulting to _day when no granularity is set — see TimeDimensionSymbol::new), while the reduce_by entry resolves to a base DimensionSymbol with the bare name. The compare never matched, so the time dim was never excluded from PARTITION BY and the window collapsed to one-row partitions.

Originally surfaced against BigQuery in production; the fix is backend-agnostic (lives in the Tesseract planner before SQL is emitted) and the included regression tests run against the existing testcontainers Postgres harness. Fixes #10854.

Changes

• rust/cube/cubesqlplanner/cubesqlplanner/src/planner/planners/multi_stage/member_query_planner.rs: introduce a single matches_partition_member(d, m) helper used at both the reduce_by and group_by filter sites in member_partition_by_logical. The helper branches on whether m carries an explicit granularity (see Implementation Details).
• rust/cube/cubesqlplanner/cubesqlplanner/src/test_fixtures/schemas/yaml_files/common/integration_multi_stage.yaml: add an amount_reduce_created_at measure (sum, reduce_by: [orders.created_at]) to the existing orders cube — fixture for the canonical regression test.
• rust/cube/cubesqlplanner/cubesqlplanner/src/tests/integration/multi_stage/reduce_by.rs (+ snapshot): add test_reduce_by_time_dim exercising the new measure with granularity: month.
• rust/cube/cubesqlplanner/cubesqlplanner/src/tests/integration/multi_stage/group_by.rs (+ snapshot): add test_group_by_time_dim_multiple_granularities mirroring the BigECommerce multi-stage shape (group_by single granularity, query projecting multiple granularities of the same time dim).

Implementation Details

The two operators have semantically distinct intents that depend on the granularity of the reduce_by / group_by entry — not on which operator it is. matches_partition_member(d, m) captures this with one rule, applied uniformly at both call sites:

• If m carries an explicit granularity (resolves to a TimeDimensionSymbol with has_granularity() == true — i.e. the user wrote <time_dim>.month / .quarter / etc.), match strictly on full_name. A group_by: [<time_dim>.quarter] matches only the _quarter projection, not sibling granularities. Symmetrically, a reduce_by: [<time_dim>.month] excludes only the _month projection.
• If m is bare (plain DimensionSymbol from reduce_by: [<time_dim>], or TimeDimensionSymbol with granularity = None), unwrap both sides to their base symbol and compare. This is the fix for the granularity-suffix mismatch from Tesseract: multi-stage reduce_by silently no-ops against type:time dimensions #10854: bare reduce_by: [<time_dim>] matches and excludes any granularity of the projection.

TimeDimensionSymbol::full_name carries a granularity suffix that defaults to "_day" when no granularity is supplied (see TimeDimensionSymbol::new); without the base unwrap, the bare entry's full_name could never match a granularity-suffixed projection.

An earlier draft of this patch applied symmetric base_of(...) unwrap to both call sites unconditionally. That was too permissive on the group_by side: when a query projected multiple granularities of the same time dim, both projections unwrapped to the same base, both matched the explicit-granularity group_by entry, both stayed in PARTITION BY, and the window aggregate degenerated to per-row sums. CI caught this against BigECommerce's multi-stage group by time dimension test in both postgres-driver and mssql-driver runs.

Testing

• cargo test --features integration-postgres --lib 'tests::integration' → 421 passed, 0 failed (testcontainers Postgres).
• cargo test --lib -p cubesqlplanner → 901 passed, 0 failed.
• cargo fmt -p cubesqlplanner -- --check → clean.
• test_reduce_by_time_dim (new) — bare reduce_by: [created_at] + granularity: month. Verified to fail (per-(status, month) sums) without the fix, passes (cross-month per-status totals: completed=1400, pending=650, cancelled=200) with the fix.
• test_group_by_time_dim_multiple_granularities (new) — group_by: [status, created_at.month] + query projecting both month and week. Verified to fail (per-(month, week) sums) under the symmetric-unwrap-on-group_by version, passes (per-month sums 500/750/1000 repeated across weeks) under the unified helper.
• Existing test_group_by_with_time (single-granularity projection) stays green.