Telemetry validation harnesses must vary production deduplication keys

Telemetry validation harnesses must vary every production deduplication-key dimension they claim to cover; otherwise new synthetic cases can increase expected capture counts while the reporter correctly suppresses them as duplicates. When normalized route participates in the fingerprint, run each route-boundary case under a representative pathname and separately test that identical errors across normalized routes are not deduplicated. This applies to synthetic capture-count tests whose cases are intended to represent distinct production incidents; it does not mean disabling deduplication or forcing unique error classes.

Evidence/example (2026-09-09, GitHub Actions and repository tests): In e3-solutions/theft PR #813, two newly registered React-boundary cases shared the validation page pathname, error class, source, flow, and load, so the production browser contract expected nine captures but timed out after reporter deduplication suppressed the additions. Supplying representative driver-stats and dispatcher paths, restoring the harness path after each case, and adding a same-error/across-routes unit test resolved the mechanism locally; CI verification remains in progress.