fix: static agent placeholder uses 5-sketch routing-connector pipeline (was single ddsketch)

[zzylol]

Why

PR #350's report flagged a real OpAMP-push gap: the controller emits the typed 5-sketch routing-connector YAML correctly, but the agent never APPLIES the OpAMP RemoteConfig push at runtime. The effective-config preview keeps showing the static bootstrap YAML loaded from the volume mount (see deploy/docker-compose/mvp-multi-stage.yml AGENT_CONFIG_A / AGENT_CONFIG_B defaults).

Previously the placeholder declared a single [gorillas3, ddsketch, batch] pipeline, so agents only ran ONE sketch (DDSketch) regardless of the controller plan. KLL / HLL / CountSketch / CountMinSketch processors never ran. The §3 architecture story ("one agent → five concurrent sketch pipelines → backend serves five concurrent query families") was broken at runtime.

What

Rewrite deploy/configs/asap-otel-agent-b6-asap-single-sketch.yaml to mirror the typed-emit shape from controller/src/config/stage_config.rs::emit_edge_yaml_5sketch_routing:

• All 5 sketch processors at top level (ddsketch, KLL, HLL, countsketch, countmin).
• routing under connectors: (NOT processors:) — OTel v0.106 removed the deprecated routingprocessor.
• 7 named pipelines: entry metrics: + metrics/raw_passthrough + 5 per-family paths.
• Each per-sketch pipeline runs gorillas3 first so cold-tier write happens on raw samples before sketch mutation.

service:
  pipelines:
    metrics:                     { receivers: [otlp], exporters: [routing] }
    metrics/raw_passthrough:     { receivers: [routing], processors: [gorillas3, batch], ...}
    metrics/ddsketch_path:       { receivers: [routing], processors: [gorillas3, ddsketch, batch], ...}
    metrics/kll_path:            { receivers: [routing], processors: [gorillas3, KLL, batch], ...}
    metrics/hll_path:            { receivers: [routing], processors: [gorillas3, HLL, batch], ...}
    metrics/countsketch_path:    { receivers: [routing], processors: [gorillas3, countsketch, batch], ...}
    metrics/countminsketch_path: { receivers: [routing], processors: [gorillas3, countmin, batch], ...}

Residual half of #350 (out of scope here)

The controller emit uses *processor-suffixed component names (ddsketchprocessor, kllprocessor, ...) and decorates each block with aggregation_id + sketch_kind keys. None of those are accepted by the patched contrib build's component registry (verified via asap-otel components and mapstructure: tags), so the controller-emitted YAML wouldn't load on agents either. That's the residual half of #350 — fix in the controller emitter, separate PR.

Verification

• asap-otel validate --config asap-otel-agent-b6-asap-single-sketch.yaml → exit 0.
• Stack boot smoke (docker compose ... up -d controller minio gateway agent-a) → Everything is ready. Begin running and processing data. Each per-family pipeline logs Starting <sketch> processor + Starting gorillas3 processor. No error|invalid|cannot|fatal|panic lines.

Test plan

• python3 deploy/configs/tests/test_static_placeholder_5sketch_routing.py — 8/8 pass.
  • All 5 sketch processors present at top level.
  • routing in connectors: (not processors:).
  • All 7 named pipelines declared.
  • Each per-sketch pipeline starts with gorillas3 and ends with batch.
  • routing.default_pipelines == [metrics/raw_passthrough].
  • context: metric on every routing table entry.
  • Routing table targets only declared pipelines.
• asap-otel validate exits 0.
• Minimal stack agent boot reports Everything is ready.

Refs #46.

🤖 Generated with Claude Code