Standalone topk unconditionally keeps __name__, even when the wrapped function drops it #710

Problem

prepend_metric_name (asap-query-engine/src/engines/simple_engine/mod.rs) runs unconditionally for every topk result, gated only on statistic_to_compute == Statistic::Topk — never on whether the wrapped expression should drop the metric name.

Real Prometheus semantics: sum_over_time/rate/sum/etc. set DropName: true on their output, and topk forwards that flag through. So topk(5, data) (bare vector selector) correctly keeps __name__, but topk(5, sum_over_time(data[5m])) should drop it — ASAPQuery keeps it in both cases. There's no DropName-equivalent concept anywhere in the codebase.

Expected behavior

For a series data{instance="i-1",job="worker"}:

• topk(5, data) → output labels: {__name__="data", instance="i-1", job="worker"} (bare vector selector keeps the name)
• topk(5, sum_over_time(data[5m])) → output labels: {instance="i-1", job="worker"} (sum_over_time drops the name; topk forwards that)

Same for count_over_time (also drops the name) — every temporal function currently supported under topk (#699) drops it, so today's output is wrong for both.

Evidence

Confirmed live via the promql-compliance differential suite (aggregations case, PR #706): every topk(k, sum_over_time/count_over_time(...)) result diffs against Prometheus with metric or timestamp differs — extra __name__="data" that shouldn't be there, once the separate label-alignment bug (fixed in #706) was no longer masking it.

Scope note

Distinct from #631 (closed, fixed by #644) — that was topk(...) as a binary-expr arm breaking joins. #644's own summary says "standalone Topk output formatting remains unchanged" — this issue is exactly that standalone case.

Related in spirit to #531's tracking list (capability-matching/planner-engine inconsistencies), though this one is a query-engine formatting bug, not a matching bug.