Simplify DDSketch quantile-ratio planning for the v1 demo

[zzylol]

Problem

Since ec2e4df ("certify DDSketch ratios with enforced input domains"), planning

quantile_over_time(0.9, data[5m]) / quantile_over_time(0.5, data[5m])

requires AccuracyEvidenceProvider::quantile_input_domain for both operands. The user-guide show_post_asap_ir path installs NoAccuracyEvidence, so the DDSketch ratio candidate is unavailable and the whole expression becomes exact KeepPreAsap. This also causes the ASAPQuery-backend issue_701_702_temporal_workloads_have_warm_candidates expectation to fail.

The current certificate is mathematically justified: it needs nonempty finite populations, bounded sample counts and DDSketch-indexable ranges, and a denominator domain that excludes zero. However, making the backend continuously produce and scope these proofs adds machinery that is not needed for the immediate v1 end-to-end demo.

v1 goal

Allow the v1 demo/integration path to expose a DDSketch candidate without requiring a backend QuantileInputDomain provider. Keep this simplification explicit and narrow. A relaxed candidate must not silently claim the formal ratio guarantee that the missing domain evidence was introduced to prove.

Choose the smallest implementation that makes the demo path work, for example an explicit demo/uncertified planning policy rather than weakening every production caller by default. The user guide and debug output must make the selected policy visible.

Acceptance criteria

• The user-guide planning path can produce a warm DDSketch candidate for the example ratio without a backend evidence service.
• The relaxed path is explicit in configuration or API use; it is not an accidental consequence of NoAccuracyEvidence.
• The relaxed candidate does not report a certified end-to-end ratio guarantee derived from nonexistent domain evidence.
• Default/certified planning behavior and exact fallback remain covered by tests.
• Add an end-to-end regression covering the user-guide/debug path and the backend warm-candidate use case.
• Document what correctness is and is not promised in v1.

Not part of v1

Do not build a general online evidence collection pipeline yet. Before v2, list and triage observed correctness and performance failures, then choose among:

• an enforced static input-domain contract;
• runtime guards for empty/non-finite/zero-denominator results with exact fallback;
• offline or online evidence supplied by the backend; or
• retaining exact fallback for unsupported ratios.

A query-time syntax check alone cannot prove that the median value is nonzero; any v2 runtime check must inspect actual results or enforce an input-domain contract.

Context

This issue follows the design discussion about the near-term value and operational overhead of accuracy evidence. Cost evidence and general workload evidence are separate concerns and are not changed by this issue.