Rate-limit the suppression branch of a browser freeze watchdog, not just the report branch

A JS event-loop freeze watchdog (setInterval heartbeat, report when drift exceeds a threshold) typically rate-limits its real freeze reports (cooldown + per-session cap) but emits an unthrottled 'suppressed' telemetry event for expected-drift cases (hidden tab, backgrounded, clock jump) so the noise remains measurable. Trap: browsers clamp timers in hidden tabs to ~60s, so EVERY tick of a backgrounded tab exceeds a multi-second stall threshold and classifies as suppressed. A handful of long-lived backgrounded tabs then emit ~1 event/min each indefinitely; in our analytics this single event type grew to 21-33% of ALL product events within days, distorting every denominator. The suppressed branch needs its own limiter; once-per-reason-per-session is usually enough, because the first occurrence carries all the diagnostic information and repeat counts of expected browser behavior are worthless. General form: any 'we suppressed X, but count it' telemetry channel needs the same rate limiting as X itself, or the counter becomes the flood.