[zzylol]

The per-point cost of the sketch branch. Base: main (the experiment-results PR below it was taken out of the stack to be rerun).

Why

On the live top-k stack the sketch branch used more CPU than the exact and raw branches (0.16 vs 0.10 and 0.01 cores at 20,000 points/s per source). A per-step timing of the branch's path showed that the Count-Min + heap update was only 0.24 of 4.1 µs per point. The rest went on building owned copies of every point:

• Decoding OTAP into observations allocated the metric name and every label as new strings.
• The per-attribute split made another copy of each point (metric, resource labels, value bytes).
• observe cloned the whole config (including a HashMap<String, f64>), took three locks, and built a new series-key string per point.

What changes

• codec::decode_each walks the OTAP view and rewrites one reused Observation per data point, passing it to a callback. decode_pdata_to_observations is now built on it, with the same output.
• matchers::per_attribute writes each split into a reused Observation, again through a callback. write_series_key fills a reused buffer and skips sorting labels that are already sorted (same bytes as before).
• PrecomputeImpl shares its config through an Arc and keeps window and stats under one lock.
• asap_sketches and exact_branch both use decode_each, so the sketch and exact pipelines still decode the same way.

Behaviour changes on bad input:

• A decode error part-way through a batch (an unknown sketch.type or a bad envelope payload) now keeps the points observed before it; previously the whole batch was dropped. The batch's remaining points are dropped and the error is logged.
• An observe error is logged once per batch instead of once per point.

Before → after

Per point, on one pinned core of a 56-core x86 server (400,000 top-k points: 100,000 Zipf routes, Count-Min 4 × 512 + top-10 heap; three identical runs). The before column comes from the same harness ported to the parent commit, which builds owned observations instead of calling decode_each. In these runs the timed split also cloned every key for the CMS-only timing, which moved about 0.05 µs from observe to the split; the harness now collects those keys in an untimed pass. The total is unaffected:

Step	Before	After
Decode OTAP into observations	2.02 µs	1.09 µs
Per-attribute split	1.14 µs	0.33 µs
observe, including Count-Min + heap	0.98 µs	0.29 µs
Total	4.14 µs	1.72 µs

On the live top-k stack (2 × 20,000 points/s, 2-minute average per stage), CPU cores per branch:

	Before	After
sketch branch-a / branch-b	0.156 / 0.160	0.074 / 0.076
exact branch-a / branch-b	0.093 / 0.098	0.063 / 0.066

The sketch branch now costs about 0.01 cores more than the exact branch, roughly the Count-Min + heap update itself. Window completion delay is unchanged (sketch 5.8 s, exact 5.2 s).

Verification

• cargo test --release --features otap-engine branch_phase_costs -- --ignored --nocapture prints the table above. It is an ignored test in otap/processor.rs.
• New unit tests: the sorted fast path of the series key gives the same bytes as the sorted walk, and per_attribute with a reused buffer gives the same observations as before.
• The full acceptance passes 29/29 on the same server with this change, with the same answers (recall@10 1.00, the same classes, drift and novelty events).
• cargo fmt --check, cargo clippy --all-targets --features otap-engine,stream-benchmark -- -D warnings and cargo test --features otap-engine,stream-benchmark (the CI commands) pass at this PR's head.
• Review follow-ups in this PR: the split timing no longer collects keys inside the timed run, a new series is inserted with the entry API (one key clone instead of two), and the series-key writers are crate-private.