Measure ASAPv1 serialization and 1,000-source merge cost per sketch

[zzylol]

Part 7 of the RFC 0001 stack: experiments 3 (serialization) and 4 (merge at scale). The open questions were whether merging around 1,000 sketches per window is too slow, and whether serialization dominates.

asap-merge-bench times, per sketch type, ASAPv1 encode and decode, and the window_merge path (decode the first payload, then merge_snapshot each of the rest) at 10, 100 and 1,000 sources. Each source sketch holds 20,000 points. --quick runs a CI-sized version. The full results are in docs/results/merge-bench.md.

Results (56-core x86 server, one pinned core, median of 5 runs)

Sketch	Bytes per sketch	Encode	Decode	Merge 1,000 from bytes	Merge 1,000 already decoded
KLL k=200	2,388	3.5 µs	4.3 µs	9.3 ms	4.7 ms
DDSketch α=0.01	682	4.4 µs	4.2 µs	4.9 ms	0.8 ms
HLL	16,720	8.3 µs	8.3 µs	17.9 ms	10.7 ms
Count-Min 4×2048	8,622	166 µs	65 µs	69.4 ms	6.7 ms
Count-Min + heap	8,767	168 µs	69 µs	80.3 ms	11.9 ms
CountSketch 4×2048	8,706	130 µs	121 µs	124.3 ms	6.8 ms

• Merging 1,000 sketches is not slow for KLL, DDSketch and HLL: 5–18 ms on one core. The cost grows linearly with the number of sources.
• For the three counter sketches, decoding ASAPv1 is 86–98% of the merge time. Merging already-decoded Count-Min sketches takes 6.7 ms, against 69 ms from bytes, and encoding is 15–50× slower than for the other sketches. That is the evidence for the RFC's open question about an Arrow-native or cheaper counter-matrix encoding.

These numbers cover single-threaded encode, decode and merge only, not network transfer.

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.