fix(chsql): synthesize TimeUnix on instant-mode VectorSetOp derived arms

[tsouza]

Summary

PR #706 introduced a per-arm canonical 4-column projection (SELECT MetricName, Attributes, TimeUnix, Value FROM (<arm>)) on every VectorSetOp arm so a UNION ALL between matrix-shape and canonical-shape arms unifies positional column types. That fix covered the matrix-mode path (range-step) but the same canonical-shape SELECT trips CH 24.x in instant mode (no step):

code: 47, message: Unknown expression identifier 'TimeUnix' in scope
    SELECT '' AS MetricName, Attributes, TimeUnix, Value FROM (...)

or, on a different folding,

code: 1, message: Resolve identifier 'TimeUnix' from parent scope only supported for constants and CTE.

The inner SELECT for an instant-mode RangeWindow / Aggregate / MetricsAggregate / MetricsHistogramOverTime only exposes (group-keys..., <ValueColumn>) — no TimeUnix column to reference. PR #701's new otelcol-observability dashboard surfaced the residue on the "Send failures (5m)" + "Processor refusals (5m)" stat panels (instant /api/v1/query, not query_range):

sum(increase(otelcol_exporter_send_failed_log_records[5m])
    or increase(otelcol_exporter_send_failed_metric_points[5m])
    or increase(otelcol_exporter_send_failed_spans[5m]))

both 502 the cerberus engine; Grafana surfaces them to the browser as a 400, and the panel-kiosk spec catches the resulting console-error trail.

Fix

vectorSetOpCanonicalArmFrag now mirrors wrapWithSampleProjection's instant branch: for derived-shape arms in instant mode, synthesize TimeUnix as (now64(9) - toIntervalNanosecond(5_000_000_000)) instead of referencing it as a column. Matrix-mode arms (OuterRange > 0) still reference TimeUnix by name because emitWindowedArrayPairsMatrix / emitWindowedArrayMatrix already alias anchor_ts AS TimeUnix on the outer SELECT.

The matrix path is unchanged — covered by the existing binary_or_increase_range_canonicalises_arms.txtar fixture. The new binary_or_increase_instant_canonicalises_arms.txtar fixture pins the instant-mode path so this residue can't silently regress.

Live verification

Against the rebuilt compose stack (PR #701 dashboards applied locally), both failing queries return HTTP 200 with the fix:

$ curl -sG -w 'HTTP:%{http_code}\n' 'http://localhost:8080/api/v1/query' \
    --data-urlencode 'query=sum by (processor) (rate(otelcol_processor_dropped_log_records[5m]) or rate(otelcol_processor_dropped_metric_points[5m]) or rate(otelcol_processor_dropped_spans[5m]))'
{"status":"success",...}
HTTP:200

$ curl -sG -w 'HTTP:%{http_code}\n' 'http://localhost:8080/api/v1/query' \
    --data-urlencode 'query=sum(increase(otelcol_exporter_send_failed_log_records[5m]) or increase(otelcol_exporter_send_failed_metric_points[5m]) or increase(otelcol_exporter_send_failed_spans[5m]))'
{"status":"success",...}
HTTP:200

Test plan

• Unit: go test ./internal/promql/ -run TestLower — passes (new fixture goldens are in)
• Unit: go test ./internal/chsql/... — passes
• Live compose stack: both query shapes return HTTP 200
• CI: compose-smoke (panel-kiosk) — must turn green to unblock PR feat(quickstart): rich ClickHouse / host / otelcol observability via OTel collector #701

🤖 Generated with Claude Code