[zzylol]

From the #799 review.

Why

The executor's DDSketch updater refused every sample <= 0 (factory.rs, value > 0.0). A DDSketch build over a gauge that ever reports exactly 0, or a negative value, therefore failed at run time with "DDS maintenance input is outside its positive representable domain". That covers #795's P5-m1 over a gauge declared non-negative, and every DDSketch selected under ignore_accuracy_guarantees. asap_sketchlib's DdSketch (sketchlib #141) has a zero bucket and a negative store, so the restriction was the executor's, not the sketch's.

What

• DDSketchAccumulatorUpdater::validate_single_input accepts zero and any finite sample whose magnitude is within ddsketch_indexable_bounds(alpha), positive or negative.
• It still refuses NaN, ±Inf, a magnitude above the range, and a nonzero magnitude below it, because the zero bucket would take such a value without the relative error.
• update_single adds the sample with DdSketch::try_add and returns its error instead of dropping it.
• The guarantee is unchanged. DDSketch's relative error alpha per quantile holds for signed samples (negative values are binned by magnitude) and is exact at zero. Whether it carries through sum and avg still depends on the samples' declared sign (feat: declare non-negative gauges so per-series quantile sketches compose through avg (#772) #780, fix(logical): a quantile of merged panes keeps its samples' sign, so pane DDSketches compose through avg #795).

How

One validation rule in the updater, so every path that updates a DDSketch takes it: the kernel factory, StateColumnUpdater, and precompute.

Before this PR

avg by (region, service, job) (quantile_over_time(0.99, data[100s])) over a non-negative gauge whose samples include 0 planned P3-m1 (merged DDSketch panes), but building a pane failed at the first zero sample.

After this PR

The same plan builds and answers. Answers equal query_time_reference and are within 0.05 of the exact average of PromQL's interpolated p99s. Signed samples, including all-negative series, work too.

Verification

• crates/executor/src/summary_kernels/factory.rs:
  • accepts_zero_and_signed_samples_within_its_indexable_range
  • quantiles_over_zero_and_signed_samples: over 0, 0, 3, 5 and over −7, −3, 0, 4, each quantile is within alpha of the sample at rank ⌈q·n⌉.
• crates/planner/tests/runtime_install.rs, through plan_installable and the stand-in runtime:
  • a_ddsketch_over_a_gauge_reporting_zero_runs_within_alpha: avg of per-series p99s with each window exactly 0, 0, 3, 5 scaled by the series, and again with 1,100 samples a third of which are zero.
  • a_ddsketch_over_signed_samples_runs_within_alpha: max of per-series p99s; four series cross zero and four are all negative.
  • Both failed before the fix with the domain error, and both match query_time_reference and are within 0.05 of exact.
• Two tests that locked the positive-only domain now check the new one: precompute_rejects_nonfinite_and_out_of_range_dds_updates (renamed) and per_sample_updates_keep_each_kernels_input_contract.
• cargo test --workspace --locked: all tests pass.