ExponentialBucketHistogram downscales far past what the data requires

Description of the bug

Three values spanning 0.143741–0.327218 s — a 2.3× range — produced a delta datapoint whose reconstructed bucket boundaries run from underflow-to-0 up through +Inf:

Count: 3   Sum: 0.627158   Min: 0.143741   Max: 0.327218

161 buckets:  85 × (0.000000, 0.000000]
              72 × (+Inf, +Inf]
               1 × (1.000000, 1.34e152]

count, sum, min, and max are all correct — only the bucket structure is wrong. The effective scale is around −9, essentially MIN_SCALE, for data that needs about 7.

Share details about your runtime

Operating system details: Alpine Linux (amazoncorretto:26-alpine), x86_64, AWS ECS
RUBY_ENGINE:      "jruby"
RUBY_VERSION:     JRuby 10.0.5.0 (Ruby 3.4 compatible)
RUBY_DESCRIPTION: not captured verbatim — JRuby 10.0.5.0 on Amazon Corretto 26
opentelemetry-metrics-sdk: 0.15.0  (relevant code unchanged on main)
Temporality: delta, via OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
Aggregation selected by a wildcard view:
  add_view('*', type: :histogram, aggregation: ExponentialBucketHistogram.new)

Share a simplified reproduction if possible

Unfortunately, we don't have a reproducible snippet as the data was captured from production traffic. If it would help, I can add instrumentation to capture the full value sequence for one affected interval and report back.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

Start at the ExponentialBucketHistogram aggregation and trace how scale and bucket boundaries are selected. Use the reported three-value range as the target case; done means the histogram no longer falls near MIN_SCALE when the data needs a higher scale, while count, sum, min, max, and reconstructed boundaries remain correct.