perf: single-pass hdr_value_at_percentiles (flat scan, +599%)

[fcostaoliveira]

Summary

hdr_value_at_percentiles resolved the requested percentiles via a per-bucket hdr_iter_next
walk. When normalizing_index_offset == 0 (the common case), replace that with a single tight
prefix-sum scan over the flat counts[] array — the index→value conversion runs only at the
crossings. Decoded/rotated histograms (normalizing_index_offset != 0) keep the offset-aware
iterator path, so behavior is unchanged there.

Percentiles must be ascending (unchanged contract); results are byte-identical.

Benchmark

Getting all 7 of {50,75,90,95,99,99.9,99.99} in one hdr_value_at_percentiles call, single core
(Intel Granite Rapids), same-session A/B on an identical workload (hdr_init(1, 3.6e9, 3), 1M
Fibonacci-spread values):

	calls/sec	µs/call
before (iterator)	12,357	80.9
this PR (single-pass)	86,403	11.6

+599% (7×). hdr_record_value and singular hdr_value_at_percentile are unchanged (controls flat).

Correctness

• ctest green; ASan + UBSan clean.
• Results byte-identical to the previous implementation (verified via a stable cross-sum over the
  7 percentiles, unchanged).
• Offset-aware path preserved: only the normalizing_index_offset == 0 case uses the direct
  counts[] scan; decoded histograms still go through the normalizing iterator.
• HDR_LOG_REQUIRED=DISABLED builds; no intrinsics (MSVC unaffected).

[fcostaoliveira]

⚠️ Conflict heads-up: this overlaps my open #137, which also rewrites hdr_value_at_percentiles (as a superset — it single-passes this function and replaces the AVX2 dispatch). Same base blob + same function ⇒ they'll textually conflict. Flagging so we don't carry two single-pass-batch PRs; happy to consolidate #137/#140 into one.

[fcostaoliveira]

Added a regression test (test_value_at_percentiles_with_offset) that drives a histogram with normalizing_index_offset != 0 (rotated counts[], as a decoded/foreign histogram would have) and asserts its percentiles match the unrotated histogram — so CI now covers the offset-aware iterator fallback (the branch that regressed in #137). ALL TESTS PASSED (19).

[github-actions]

🤖 Automated first-pass review — a human maintainer's review is still required before merge.

The rewrite looks behaviour-preserving to me: with normalizing_index_offset == 0, counts_get_normalised() degenerates to counts[index] and move_next() sets iter.value = hdr_value_at_index(h, counts_index), so the fast path is the same index-by-index walk with the per-bucket bookkeeping dropped. No struct layout or signature change, so no SOVERSION question here.

The one thing worth raising isn't in this diff. hdr_value_at_percentile() resolves through get_value_from_idx_up_to_count_scalar(), which reads h->counts[idx] directly and never consults normalizing_index_offset — so the offset-awareness this PR is careful to keep for the plural call is already gone from the singular one on main. If test_value_at_percentiles_with_offset were pointed at hdr_value_at_percentile() I'd expect it to fail. Nothing in the C port ever sets a non-zero offset itself, so it only turns up when decoding a payload written by an implementation that does (Java's shift operations), which makes it narrow but real. Separate PR, but worth a look from whoever touches that path next.

Minor: that's now three hand-written prefix-sum scans over counts[] in this file (scalar, AVX2, and this one), and the new one can't reach the AVX2 dispatch from #134. Fine as-is, but the next change here has three places to touch.

The test itself reads fine — poking the fields directly is the only way to get a rotated histogram without an encoded payload, and rotated is hdr_init'd with the same parameters as raw_histogram, so counts_len matches. hdr_close rather than free is right.

I can't reproduce the benchmark, and CI doesn't measure performance; the per-PR fuzz gate is ASan only (UBSan is the weekly batch job), so your local ASan/UBSan run is what actually covers that.