feat(pipes): edge-cacheability + TTL control for public read bursts #296

Area: pipes · cache — public-burst cacheability knobs · found via WaveHouse-Stats dogfooding (sizing stats.wavehouse.dev, WaveHouse-Stats#20)

Two related levers for absorbing public pipe-read bursts (e.g. an HN spike → every visitor's reads ride the tunnel to one box). Neither blocks launch — the origin Ristretto cache + singleflight already bound ClickHouse load — but both widen the burst headroom for the public read surface.

• Per-pipe (or per-deployment) cache TTL override. Pipe TTL is derived purely from query duration — cache.QueryTimeToTTL(queryDuration) (internal/api/pipes.go:177; clamp min 10s / max 1h at internal/cache/cache.go:37-45, whose own comment says an override "is needed"). Count pipes run in single-digit ms → always the 10s floor; the window can't be widened without making the query slower. Want: pin a hot public pipe to e.g. 60s by policy.
• Emit Cache-Control on pipe responses so a CDN can cache them. GET execution already landed (internal/api/router.go:147 r.Get("/pipes/{name}", Execute) — the dogfooding doc's "POST-only" note is stale), but the handler sets no Cache-Control (only Content-Type + X-Cache), so every read is cf-cache-status: DYNAMIC and transits edge → tunnel → origin even inside the TTL window. Add an opt-in Cache-Control: public, max-age=<ttl> (query-string params form the cache key naturally) so the edge absorbs public count-pipe reads.

Related: #280 (SDK cacheTTL() silent no-op), #178 (pipe cache invalidation), #245 (pipes under policy).

From WaveHouse-Stats WAVEHOUSE-FEEDBACK.md dogfooding (dev 2ee48a1); validated by code-read against b7c69ef (main) on 2026-06-08 via /pm-triage.