fix(agent): split chained sketch pipelines so windowed processors don't drop each other's output

[zzylol]

Summary

When an agent config chains two windowed sketch processors — e.g. b3-delta's `[ddsketch, HLL, batch]` — the agent silently emits nothing. Symptom: ddsketch's `output_metric_points_total` grows but `exporter_sent_metric_points_total` never appears. This was the actual blocker for warm-tier sketch verification.

Root cause

Both `ddsketchprocessor` and `hllprocessor` (and the other windowed sketch processors) handle window mode like:

```go
case ModeWindow:
p.accumulateIntoWindow(md)
return nil // <-- inputs are NOT forwarded
```

In window mode the processor is its OWN producer — it accumulates inputs into windowed state and emits on its own timer. It does not forward inputs synchronously.

So the chain `[otlp -> ddsketch, HLL, batch -> otlp/gateway]` actually behaves like this:

1. otlp delivers raw fake-exporter metrics → `ddsketch.ConsumeMetrics`.
2. ddsketch accumulates, returns nil. HLL never sees the raw inputs.
3. ddsketch's window timer fires → emits 1000 typed-DDSketch metrics → calls `HLL.ConsumeMetrics(typed DDSketch payload)`.
4. `HLL.accumulateIntoWindow`'s switch only handles `MetricTypeGauge` and `MetricTypeHLLSketch`. Typed DDSketch metrics fall through and HLL silently drops them (no default case, no pass-through to nextConsumer).
5. batch processor sees nothing.

Live confirmation before the fix: ddsketch input/output = 18000/2000, HLL input/output = 2000/0, batch processor reports only `metadata_cardinality=1` — instantiated but never received items.

Fix

Split into per-sketch pipelines. The OTLP receiver fans out to every pipeline that references it, so each sketch processor sees every incoming batch independently:

```yaml
service:
pipelines:
metrics/ddsketch:
receivers: [otlp]
processors: [ddsketch, batch]
exporters: [otlp/gateway]
metrics/hll:
receivers: [otlp]
processors: [HLL, batch]
exporters: [otlp/gateway]
```

Applied to all three configs that chained windowed sketch processors:

• `sketchcol-agent-b2-full.yaml` (paper baseline B2)
• `sketchcol-agent-b3-delta.yaml` (paper baseline B3)
• `sketchcol-agent-b4-tunable.yaml` (paper baseline B4)

Each comes with a comment block explaining the gotcha so the next person adding a sketch processor doesn't recreate the bug.

Verification

End-to-end with `b3-delta` after the fix:

Stage	Before	After
ddsketch processor output	2000	2000
HLL processor output	0 (in same pipeline)	n/a (independent pipeline)
Agent exporter sent	0 / metric absent	2000
Gateway receiver accepted (gRPC)	0 / metric absent	2000
Gateway exporter sent to backend	0	1000 (first batch)
Backend OTLP ingest	0 routed	1000 routed, 0 decode-failed

Backend log on first agent window flush:
```
OTLP modified-proto Ddsketch received
(metric=http_requests_total_latency_ms_quantile, dps=1000); decoder is PR B
OTLP modified-proto sketch ingest:
1000 routed, 0 decode-failed (fallback), 0 unconfigured
```

PromQL query path matches inference patterns and looks up the right `agg_id` in the precompute store. Remaining no-result on `quantile_over_time(...)` is downstream and out of scope here — see follow-ups below.

Two adjacent issues found during e2e (separate from this PR)

1. Delta-encoded sketches fail to decode at backend. Second window's flush logs `1000 routed, 1000 decode-failed (fallback)`. The agent has `delta_transmission: true` and emits proto_full only for the first window, then proto_delta for subsequent windows. The backend's modified-OTLP DDSketch decoder doesn't yet handle `DDSketchEncodingProtoDelta`. (See the `ddsketchprocessor.decodeDDSketchDataPoint` stub which already documents this.)
2. Precompute store empty on query. Even after first-window data routes successfully (1000 routed, 0 decode-failed), `Query execution failed: No precomputed outputs found for metric`. Possibly a windowing/timestamp alignment issue between the agent's 60s window emit and the backend's 30s tumbling window in `backend-streaming.yaml`. Worth a focused look at the precompute engine's window flush + query lookup timestamps.

These are independent of this PR — agent → gateway → backend OTLP ingest works.

Test plan

• `docker compose ... up -d` with the new b3-delta config — agent's exporter starts sending after first 60s window.
• Gateway gRPC receiver accepts the typed sketch payload (transport=grpc, accepted_metric_points_total grows).
• Backend OTLP receiver decodes and routes typed DDSketch payloads to precompute engine.
• Once delta-decode + store-window issues are addressed, full PromQL flow returns expected envelope.

🤖 Generated with Claude Code

[zzylol]

Superseded by #211 — the proper fix is at the processor level (forward inputs through windowed processors), so the original chained [ddsketch, HLL, batch] config works directly without needing per-pipeline split. The user's design goal is one pipeline that supports any controller-chosen combination of sketches, which #211 enables.