[processor/delta_to_cumulative] Fix exponential histogram bucket limit rounding

[SerhiiGoTolstoy]

Description

Delta-to-cumulative aggregation can produce exponential histograms with 161 or 162 buckets despite its 160-bucket limit. Limit() truncates both bucket-range endpoints toward zero, so its predicted size can be smaller than the result of Collapse() and Merge().

For example, the range [1, 321) contains 320 buckets. The current calculation predicts 160 buckets after one downscale step, but the actual result spans indices 0 through 160 and needs 161 buckets. Ranges crossing index zero can exceed the limit by two buckets.

This change rounds the lower index down and the exclusive upper index up, including negative indices. It makes scale selection match the existing bucket-merging algorithm. Observation counts are preserved, and the tests check that ranges which fit do not receive unnecessary downscaling.

I encountered this while using the Collector for AWS Lambda in a production workload handling billions of requests, where oversized histograms were rejected by AWS. The regression tests use small synthetic inputs to isolate the defect; they do not replay the rejected production payloads. The faulty calculation was present in v0.151.0 and is still present on the main branch used for this PR.

Link to tracking issue

No separate issue. This PR includes regression tests that reproduce the defect.

Testing

Eight regression cases exercise Limit(), Downscale(), and Merge() together. They cover positive and negative offsets, a range crossing zero, repeated downscaling, and ranges that fit the limit. They also check that both observations remain in the merged histogram.

• Before the fix, five of the eight cases fail: four produce 161 buckets and one produces 162. The three control cases pass.
• After the fix, all eight cases pass.
• make test in processor/deltatocumulativeprocessor: all 115 component tests pass with the race detector enabled.
• make lint in the same directory: passes.

Documentation

Added a changelog entry and a code comment explaining the rounding rules. No configuration or public API changes.

Authorship

I do not know Go. I used Codex to investigate the issue and write the implementation, regression tests.

• I, a human, wrote this pull request description myself.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: SerhiiGoTolstoy / name: Serhii (0dff1df, e4d934d)

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Read our Contributing Guidelines.
• Sign the CLA if you haven't already.
• Follow the OpenTelemetry Generative AI policy: disclose any AI use in your contribution, and communicate (PR descriptions, review replies) in your own words rather than AI-generated text.
• Give reviewers at least a few days before pinging them for feedback.
• If you need help with general setup, development process, or contributor etiquette, ask in #opentelemetry-new-contributors.
• First-time contributors should keep at most one PR marked as ready for review until their first PR is merged; once two are open for review, any further PR is automatically converted to draft.
• If your change isn't one of our priority components, reviews may take more time.
• Raise technical or Collector-specific questions in #otel-collector-dev or a Collector SIG meeting.

[SerhiiGoTolstoy]

I will be transparent, i dont know GO and just discovered this repo today to implement OTLP collector for my aws Lambda env. The issue was caught in production under real load of billion of requests. Proper unit test were added to prove the issue.

[singhvibhanshu]

Please check the Authorship checkbox.

[singhvibhanshu]

/workflow-approve