Small-sample quantile_over_time p99 diverges from Prometheus interpolation semantics

[zzylol]

Context

Found while developing/reviewing the raw-oracle process E2E in #478.

Using this deterministic raw fixture:

[10, 12, 15, 20, 30, 45, 60, 80, 100]

for:

quantile_over_time(0.99, metric[10s])

the Prometheus-style linear interpolation oracle gives 98.4, while the production backend's DDSketch path returned approximately 80.6522. Relative difference is about 18%, despite DDSketch alpha 0.01.

Changing the stable acceptance fixture to p50 avoids conflating interpolation definitions, but leaves the high-quantile semantic difference unresolved.

Why this matters

Prometheus clients expect quantile_over_time semantics. DDSketch is approximate, but the exposed accuracy envelope should have a clearly defined relationship to the Prometheus reference value. A discrete lower-rank selection that is far outside the advertised relative error is surprising for small populations.

Reproduction approach

Use the process fixture in data_plane/tests/promql_differential_process_e2e.rs, set the quantile to 0.99, and retain the nine raw values above.

Questions to resolve

1. Is the ASAP result intended to approximate Prometheus's interpolated quantile, nearest rank, or the sketch library's native quantile definition?
2. Does the advertised DDSketch alpha apply to the selected population value or to the Prometheus-interpolated result?
3. Should small populations use an exact auxiliary path or a different error annotation?

Done when

The contract is documented and a strict process-level test compares small-N p90/p99 results against the chosen reference semantics. If Prometheus compatibility is intended, the returned value and declared accuracy must be consistent with the Prometheus oracle.