security(query): ClickHouse resource caps not enforced server-side — send per-query Settings (max_execution_time/max_memory_usage/max_rows_to_read) #316

Area: query · api — security (DoS, missing server-side enforcement) · found via pre-launch audit

Expected: the policy's max_execution_time_ms (and an implicit row/memory budget) is enforced by ClickHouse server-side, so a query can't outrun it during a server-side scan/merge/aggregation phase.

Actual: cmd/wavehouse/main.go:151 clickhouse.Open(&clickhouse.Options{...}) passes no Settings map, so no max_execution_time / max_memory_usage / max_rows_to_read / max_result_rows ever reaches CH. The only budget a public query gets is a Go context.WithTimeout (min(MaxExecutionTimeMs=3000, query_timeout)), which (a) cancels only while the client goroutine is in the block-read loop — a long server-side aggregation phase runs to completion first — and (b) bounds neither memory nor rows read server-side, so a query can allocate GBs of aggregation state within the 3 s budget. Re-verified no Settings on 40619b8a.

Impact: the systemic root that makes the rest of the DoS set worse — it removes the mitigation one would assume protects the box, so the heavy-aggregation and pipe cache-bypass findings are each worse than the policy caps imply. Latent on today's tiny corpus; grows directly with table size.

Scope: pass per-query CH Settings derived from the role's caps.

Related: #232 (per-role lookback), epic(security) DoS / resource-exhaustion hardening, the pipe cache-bypass issue.

From WaveHouse-Stats pre-launch security audit (WAVEHOUSE-FEEDBACK.md dogfooding), audited dev 60fed15 / DoS-pass 0b62271; re-verified live on 40619b8a (2026-06-10). Full repro: WAVEHOUSE-CRASH-REPORT.md (private, R1). Filed via /pm-triage.