feat: execute TopK exact values through candidate-filtered Prometheus

[zzylol]

A hybrid topk(2, sum by (job) (rate(...))) plan previously maintained a local exact counter subtree alongside its CMS candidate heap. That duplicated exact computation and made the warm path state cost scale with the raw series count.

This change gives the installed typed DAG a candidate-dependent Prometheus leaf. The backend reads the shared CMS candidate node once, injects an anchored job matcher into the exact inner PromQL through the PromQL AST, asks Prometheus only for those candidates, and then intersects/reranks the normalized exact vector. Empty candidate sets return immediately without an RPC. Candidate requests use form POSTs so larger heaps do not hit URL limits, and candidate/query size limits turn unsafe requests into the existing whole-query capability fallback.

The compiler now installs only the CMS-with-heap for this hybrid branch; it does not provision an Increase/exact-counter materialization. Existing non-hybrid plans keep their prior local exact behavior. Successful summary-candidate plus remote-exact execution reports x-asap-execution=hybrid; exact_fallback remains reserved for whole-query Prometheus fallback. The calibration guard distinguishes both plan shapes and fail-closes the new branch unless it records one CMS read, one candidate-filtered exact RPC/evaluation, zero local exact state, and explicit hybrid provenance.

Validation:

• cargo fmt -p control_plane -p data_plane -- --check
• cargo test -p control_plane --lib (708 passed)
• cargo test -p data_plane query_engines::asap_query_engine --lib (122 passed)
• cargo test -p data_plane logical_provenance_tests --lib (5 passed)
• python3 -m unittest discover -s tools/o11y-execution -p 'test_*.py' (46 passed)
• evaluation-11 on the preceding implementation commit completed 20/20 correctly with one global CMS, no local exact counter, one shared summary readout, and one candidate-filtered exact RPC; the final classification-only SHA is being rerun