[zzylol]

Part 4 of the telemetry-functions stack: use case 1, cardinality and uniqueness.

What it adds

• per_attribute in asap_sketches: each point becomes one series per attribute key (attribute.key=<key>, "*" = every key) whose values are sketched. An HLL then counts distinct values per key.
• A classifier shared by the detector and exact paths. Each key is compared with its own last 10 windows: identifier-like when distinct / points ≥ 0.9, growing when distinct is more than 20% above the baseline mean, otherwise stable. The class is a gauge (asap_cardinality_state), and class changes are OTLP log events sent to Loki.
• The cardinality scenario: user.id unique, k8s.pod.name growing 5% per minute, http.route and http.method fixed. Plus a dashboard.
• Fix: processors ack their consumed inputs. asap_sketches, window_merge and the answer processors keep their input in state but never acked it, so an upstream node that waits for acks (the official fanout does by default) held each message until timeout. That cut a branch to about a quarter of the offered rate: 640,000 instead of 2.4 million points per window. They now ack. Every window delivers the full rate.

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

Key	Exact	Sketch	Class (sketch / exact)
user.id	640,000	644,851 (+0.76%)	identifier-like / identifier-like
k8s.pod.name	51	51	growing / growing (after baseline)
http.route	20	20	stable / stable
http.method	5	5	stable / stable

(The user.id row was measured before the ack fix, when the window held 640,000 points.)

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.