Greptile Summary

This PR fixes a real performance regression introduced by #51950: calling prune() on every check() caused a full O(n) linear scan over up to 5,000 cache entries, blocking the Node.js event loop and producing the 33–122 s message delays on active Discord servers.

Changes:

• src/infra/dedupe.ts: prune() is now called lazily — only when cache.size > maxSize — eliminating the per-message O(n) scan. The newly-touched key is always placed at the tail of the Map, so it is safe from the subsequent pruneMapToMaxSize call.
• src/infra/map-size.ts: The while-loop is replaced with a cleaner single forward-pass that pre-computes deleteCount = map.size - limit and breaks after exactly that many deletions. Mutating Map entries for already-yielded keys during for…of iteration is well-defined per the ECMAScript spec.

Minor behavioral trade-off: TTL-expired entries are no longer eagerly removed on every call; they linger until the cache grows beyond maxSize. For the dedupe use-case this is fine — individual lookups still perform per-key TTL checks in hasUnexpired, and a full prune fires whenever the cache tips over the size limit. Maximum retained entry count remains bounded at maxSize + 1.

The fix is well-tested (5 dedupe tests + 2 map-size tests) and logically sound.

Confidence Score: 5/5

• Safe to merge — targeted, correct fix with no regressions and good test coverage.
• The root cause is well understood, the fix is minimal and scoped entirely to the hot path, the Map-mutation-during-iteration pattern is spec-compliant, and the intentional TTL trade-off is acceptable for a bounded dedupe cache. All edge cases (maxSize=0, fractional maxSize, duplicate-key promotion, explicit clear) are covered by tests.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(infra): lazy prune in DedupeCache to..." | Re-trigger Greptile}