fix(target-allocator): sort labels in processTargetGroups to prevent hash collisions

[gracewehner]

Description

When processTargetGroups builds labels for each target, it uses a struct-copy of the group ScratchBuilder and appends target labels. The resulting label set has two independently sorted sublists (group labels, then target labels) but is not globally sorted.

labels.Labels.Get() (in the stringlabels build, the default) uses a linear scan with sorted-order early termination: if it encounters a label name whose first byte is greater than the search key, it stops immediately and returns empty. When a group label like vendor (first byte v=118) precedes __address__ (first byte _=95), Get("__address__") sees 118 > 95 and breaks early — returning "".

This causes relabel_configs that read source_labels: [__address__] to produce identical output for all targets in the group, creating hash collisions in the allocator's map[ItemHash]*Item. The last target silently overwrites all others.

Fix

Replace the struct-copy pattern with a merge-sort that interleaves the sorted group labels and sorted target labels into globally sorted output. Uses ScratchBuilder.Overwrite() to reuse internal buffers, achieving ~0% overhead vs the buggy baseline in benchmarks.

Testing

• Added regression test TestSortedLabelsBlackboxRelabeling that reproduces the exact customer scenario (blackbox exporter with vendor group label + 2 targets)
• Added workaround validation tests confirming which customer workarounds are effective
• All existing tests pass (make precommit clean — fmt, vet, lint, 1955 tests, ensure-update-is-noop)

Customer Impact

This bug silently drops scrape targets when:

1. static_configs has group-level labels AND multiple targets
2. relabel_configs reads __address__ (which most configs do)
3. The group label name sorts alphabetically after __address__ (any label starting with a-z)

Workaround: Remove group labels from static_configs and add them via metric_relabel_configs instead.

Link to tracking issue

Fixes open-telemetry/opentelemetry-operator#XXXX