refactor(query-engine): Split enable_topk into limiting vs formatting flags

[akanksha-akkihal]

Summary

Refactor the query engine's single enable_topk boolean into two flags so PromQL and SQL top-k can share the heap-based ranking path without forcing PromQL-specific output shaping on SQL.

---

Background

execute_query_pipeline / execute_context previously took one flag:
execute_query_pipeline(context, enable_topk: bool)

When enable_topk was true, the pipeline did all of the following together:

• Limiting — use sketch-heap candidates and truncate results to k
• Sorting — order rows by value descending (top-k semantics)
• Formatting — prepend the metric name to each row's labels (PromQL instant-vector / {__name__, …} shape)

That coupling worked for PromQL topk(k, …), which needs all three.

It does not work for SQL top-k, which needs limiting + sorting but must not prepend the metric/table name to labels. SQL should return bare (group-by columns, value) rows, e.g. (srcip, count).

With a single flag, SQL had no way to get heap-driven top-k without also getting PromQL label formatting.

---

Proposed Change

Replace enable_topk with two separate flags:

Flag	Purpose	PromQL top-k	SQL top-k	Other queries
enable_topk_limiting	Truncate sorted results to k	true	true (when top-k detected)	false
enable_topk_formatting	Prepend metric name to label values	true	false	false

Note: Sorting for Statistic::Topk remains always on (not gated by either flag). Both SQL and PromQL need descending order before truncate(k); collection returns heap keys in a HashMap with undefined iteration order.