[timeseries] Reduce evaluator label-copy churn with copy-on-write label sets

[apurvam]

Issue #348 reduces repeated warm-query evaluator work by adding query-scoped caches and shared canonical labels in query artifacts.

That work deliberately stops short of introducing copy-on-write labels through the evaluator itself.

What remains after #348:

• EvalSample / EvalSamples still carry HashMap<String, String> labels
• label mutation sites still allocate and copy eagerly in:
  • vector-vector binary ops
  • on(...) / ignoring(...)
  • group_left(...) / group_right(...)
  • deferred __name__ drops
  • topk / bottomk
  • label_replace
  • label_join

This issue should introduce a copy-on-write evaluator label type, along the lines of Shared(Arc<[Label]>) plus Owned(Vec<Label>), so labels stay shared while they are only being read and only promote to owned form on mutation.

Expected gains:

• lower allocator churn on high-cardinality warm queries where labels are read many times but mutated on only a subset of paths
• lower label-copy overhead on binary-op-heavy queries and label-manipulation-heavy queries
• a better foundation for any future step-table / preload work

When the gains are realized:

• after Issue [timeseries] Reduce repeated work in the evaluator #348 has landed
• when post-348 profiles still show label-map allocation, label cloning, or label hashing as a top warm-query CPU or allocation cost
• most likely on:
  • vector-vector binary expressions
  • on(...) / ignoring(...)
  • group_left(...) / group_right(...)
  • label_replace
  • label_join
  • topk / bottomk
• not expected to matter much on very simple selector-only queries

Suggested acceptance criteria:

• profiling after [timeseries] Reduce repeated work in the evaluator #348 shows label allocation/mutation remains hot enough to justify the added complexity
• the new label type is fully internal to the evaluator path
• PromQL semantics remain unchanged
• benchmark notes show an additional warm-query improvement on the targeted query shapes