Reduce BenchmarkValidation overhead by caching safe-output field order

[Copilot]

BenchmarkValidation regressed due to repeated work in validation hot paths. The dominant cost was re-sorting safe-output field mappings on each validation/replay pass, inflating CPU and allocations.

• Root-cause reduction in validation path

  • Added a sync.Once-backed cache for sorted safeOutputFieldMapping keys in samples_validation.go.
  • Replaced per-call sorting in validateSafeOutputsSamples with cached lookup.

• Keep replay path consistent

  • Updated collectSampleEntries in samples_replay.go to use the same cached field-order helper, preserving deterministic ordering while removing duplicate sort work.

• Targeted coverage

  • Added TestGetSortedSafeOutputFieldNames_MatchesSortedKeys to confirm:
    • cached ordering matches canonical sorted keys
    • repeated calls reuse the same backing slice behavior (guarded for non-empty slices)

var (
	sortedSafeOutputFieldNamesOnce sync.Once
	sortedSafeOutputFieldNames     []string
)

func getSortedSafeOutputFieldNames() []string {
	sortedSafeOutputFieldNamesOnce.Do(func() {
		sortedSafeOutputFieldNames = sliceutil.SortedKeys(safeOutputFieldMapping)
	})
	return sortedSafeOutputFieldNames
}

[github-actions]

Hey @Copilot 👋 — great to see a fix being kicked off for the BenchmarkValidation performance regression (25.4% slower, 38,168 ns/op vs historical 30,437 ns/op). This is squarely the right thing to work on.

This PR is still a fresh draft with no code changes yet, so a couple of things to keep in mind as it takes shape:

• Add a description — once a plan or approach is decided, update the PR body to explain what is being changed and why (e.g. which code path was identified as the hotspot, what optimization was applied).
• Include benchmark tests — since this is a performance regression fix, please include before/after go test -bench=BenchmarkValidation output in the PR body or as a comment, and consider adding or updating the benchmark itself so the regression can't silently reappear.

When ready, here's a prompt you can use to drive the implementation:

Fix the 25.4% performance regression in BenchmarkValidation (currently 38,168 ns/op vs historical baseline of ~30,437 ns/op).

1. Run `make bench-memory` and `go test -bench=BenchmarkValidation -benchmem -count=5 ./...` to reproduce and measure the current state.
2. Use `go tool pprof` to identify the hotspot introduced by recent changes to validation logic.
3. Apply the minimal targeted fix to bring ns/op back to or below the 30,437 baseline.
4. Confirm with `benchstat` comparing before/after runs (at least 5 iterations each).
5. Update the PR body with: (a) root cause identified, (b) fix applied, (c) before/after benchmark numbers.

Generated by ✅ Contribution Check · 122 AIC · ⌖ 17.8 AIC · ⊞ 6.2K · ◷