resolve race condition in result deduplication cache

[kvnphvm]

Description:

Between checking if a result is in the deduplication cache and adding it, another goroutine could add it, or it could be evicted. This contributes to varying result counts.

Change to ContainsOrAdd so that it is one atomic step

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

---

Note

Medium Risk
Changes concurrent deduplication on the shared notifier dispatch path, which directly affects reported finding counts; scope is narrow and covered by new concurrency tests.

Overview
Fixes inconsistent finding counts when multiple notifier workers process the same scan result at once.

The notifier dedupes non-reverification results (SecretID == 0) via a shared LRU cache keyed by an MD5 of detector name, type, raw secret, and source metadata. That path used a separate lookup then insert, so two workers could both see a miss and dispatch the same finding twice. The change replaces that with ContainsOrAdd so check-and-insert is one step, with a short comment that the cache is shared across workers.

Tests add a mutex on captureDispatcher for concurrent notifier use, and TestNotifierWorker_ConcurrentDuplicatesDispatchedOnce runs 16 workers over 1,000 distinct secrets with 16 copies each (cache sized to avoid eviction) and asserts exactly one dispatch per secret.

^{Reviewed by Cursor Bugbot for commit 5c5e416. Bugbot is set up for automated code reviews on this repo. Configure here.}