Run every stage as a pinned collector container; sketch vs exact answers with bounds

[zzylol]

Part 3 of the RFC 0001 stack. This is the deployment the use cases run on.

Before → after

• Before: the production asap_sketches processor only ran in-process or behind the file-passing demo. The container benchmark used a separate model processor.
• After: every stage is the official OTAP engine (asap-collector: the upstream controller with the ASAP nodes linked in), in its own container pinned to its own CPU, talking OTLP/HTTP over the network. The sketch answers are shown next to exact answers computed from the same traffic.

generator-a -> branch-a --sketch--> merge -> detector --> Prometheus -> Grafana
generator-b -> branch-b --sketch--/
                  \--raw copy (official fanout)--> exact ------/

New pieces

• asap-collector: the upstream df_engine startup (admin /metrics, /readyz, signals) with the ASAP nodes registered.
• window_merge: merges sources' sketches by the window they describe, not by arrival time, and emits a window a grace period (5 s) after it ends. Later arrivals are counted as late.
• sketch_detector: turns merged windows into answers with bounds. HLL ±1.96 standard errors; KLL quantiles at q ± the normalized rank error; Count-Min lower bound = estimate − e/w·N.
• exact_answers: the same answers from every raw point by event-time window. It is both the ground truth and the exact baseline. Both emit asap_quantile, asap_distinct, asap_topk and asap_points, labelled method="sketch" or "exact", as plain OTLP gauges with labels on each point.
• aggregate_by is exposed in the processor config.
• Fix: tumbling windows close by event time. Windows used to close on a timer started at the first message, so up to a window of later points landed in the previous window. Measured before the fix: the first window held 751,060 points in the sketch against 175,630 exact. A batch whose event time passes the window's end now closes it first, and the idle timer runs every second. After the fix, sketch and exact hold identical point counts in every window.
• deploy/telemetry-functions: Dockerfile, compose.yaml, stage pipelines, Prometheus (OTLP receiver plus a scrape of each engine's CPU, RSS and bytes), Grafana and Loki, and run.sh.

Result (56-core x86 server, 1-minute windows, 20,000 points/s per source)

For the busiest route, the sketch p99 was 199.5 ms against 201.7 ms exact, inside the sketch's bound of 166–295 ms. For routes with 20,000–100,000 points per window, the p99 can differ from exact by 10–40%. That is KLL's rank guarantee (about 1.3% at k = 200) in a log-normal tail, where a small rank shift is a large value shift; the bound covers it. The accuracy-vs-k experiment comes in a later PR.

Validation

Run on a 56-core x86 server with deploy/telemetry-functions/run.sh. cargo fmt --check, cargo clippy --all-targets --features otap-engine,stream-benchmark -- -D warnings and cargo test --features otap-engine,stream-benchmark pass at this PR's head. The end-to-end acceptance checks come in a later PR of this stack.