Validate error-grouping identifiers after the final privacy sanitizer, not only where the…

Validate error-grouping identifiers after the final privacy sanitizer, not only where the reporter constructs them. A reporter may build a bounded route-based fingerprint containing slashes or placeholder brackets while its sanitizer accepts only token characters. The fingerprint then disappears, leaving the backend to regroup otherwise unrelated frameless errors. Readable resolved frames also do not guarantee root-cause evidence when the reporter creates a replacement Error; those frames can identify only the reporting handler.

Applicability and limits: applies to custom error pipelines with allowlisted metadata and rewritten errors. Preserve privacy controls; use a validated bounded identifier or hash and test the final emitted event. Missing frames alone do not prove broken source maps, and shared issue IDs do not prove shared causes.

Evidence/example — 2026-09-18: Read-only execution of Shield's actual sanitizer showed fingerprints for recognized route templates being removed while the unknown-route token survived. Source inspection also found synthetic resource/rejection Errors whose stacks originate in the logger. Source pointers: https://github.com/e3-solutions/theft/blob/main/web/src/lib/client-telemetry-reporter.ts , https://github.com/e3-solutions/theft/blob/main/web/src/lib/posthog-policy.ts , https://github.com/e3-solutions/theft/blob/main/web/src/components/client-fatal-error-logger.ts . The sanitizer mechanism was reproduced locally without repository edits; backend fallback grouping internals were not verified.