…831)

* Benchmarks: surface profiler per-sample latency via custom XCTMetric

The five sampling-scenario profiler benchmarks need a Thread.sleep
inside the measure block to give the sampler real time to fire, so
wall-clock time is dominated by the sleep rather than profiler
overhead. Replace the wall-clock metric on those tests with a custom
XCTMetric that carries profile.metrics.avgNs (per-sample capture
latency in seconds), and teach parse_benchmarks.py to prefer kscrash.*
custom metrics over wall clock and to honor per-test threshold
overrides. Other tests in the suite are unaffected.

Off-simulator runs assert at least one sample was captured per
iteration so a sampler regression fails loud instead of rendering as
Excellent.

* Benchmarks: extract measurePerSampleLatency helper, tighten assertion gate

Address Copilot review: dedupe the per-iteration metric setup and
sample-count assertion across the five sampling-scenario tests by
extracting a measurePerSampleLatency helper that takes a body returning
ProfileMetrics?.

Also tighten the assertion gate from !targetEnvironment(simulator) to
(os(iOS) || os(tvOS)) && !targetEnvironment(simulator) &&
!targetEnvironment(macCatalyst). The previous gate let the assertion
fire on the macOS host where swift test runs the benchmarks under
sanitizers; the slowed-down dispatch source can't honor 5-10 ms
intervals on a non-device, so 0-sample iterations are normal there.
The assertion now runs only on real iOS/tvOS device, which is what we
actually want to monitor.

* Benchmarks: migrate PerSampleCaptureLatency tests to custom XCTMetric

PerSampleCaptureLatency and PerSampleCaptureLatencyDeepStack used to
compute per-sample latency stats and dump them via print(), so they
took up rows in benchmark-tests.json without ever populating any data
in the PR comment table. Reuse the measurePerSampleLatency helper so
they emit the same kscrash.profiler.persample_avg custom metric as the
five sampling-scenario tests, and add per-test threshold overrides
suited to per-sample microsecond scale (deeper stack gets a looser
band because comprehensive unwind takes longer per sample).

* Benchmarks: gate ProfilerSampleMetric on !os(watchOS)

KSCrash's SwiftPM platforms include watchOS 5, where XCTMetric and the
XCTPerformanceMeasurement* APIs are unavailable. Wrap the file contents in
the same guard already used by KSProfilerBenchmarks.swift so watchOS builds
of the benchmarks target compile.

* Benchmarks: fix Sample64 stack truncation, tune device-realistic thresholds

Two issues surfaced by reviewing the on-device benchmark output:

1. testBenchmarkHighFrequencySampling and testBenchmarkSampleRetrieval
   profiled pthread_self() with Profiler<Sample64>. Under XCTest the test
   thread holds 60+ stack frames, exceeding the 64-address Sample64 buffer.
   The profiler discards truncated samples (Sample.swift:108 sets
   addressCount to 0 when isTruncated), so every captured sample was thrown
   away, yielding count=0 and avgNs=0, which the parser formatted as
   "<1 us, Excellent". Switch both tests to Sample128 so captures fit.

2. The on-device-only assertion (XCTAssertGreaterThan(metrics.count, 0))
   masked the bug above on macOS swift test runs. Drop the platform guard
   so a regression that yields zero samples fails loud everywhere; the
   prior comment about dispatch-timing unreliability was wrong, the real
   failure mode is sample truncation.

3. Thresholds in benchmark-tests.json were calibrated for the Sample64
   bug's fake "<1 us" reading. Loosened against actual device numbers
   from the BrowserStack iPhone 17 Pro run so the per-sample latency tests
   (which measure stack-walk cost, not interval) classify reasonably:
   per-sample latency tests get ms-scale thresholds matching the 6-7 ms
   capture cost on slower iOS hardware.