fix: don't emit findings from clean "No material issues" lenses

A lens whose verdict is "No material issues found" still tends to write
path:line references — but as verification notes ("verified X at
file:line is safe"), not problems. The telemetry was extracting those as
findings, which (a) pollutes the gadfly-reports store with false
positives and (b) unfairly penalizes thorough reviewers that do clean
passes — the FP penalty hit clean security passes from claude-code/sonnet,
deepseek, and minimax even though they correctly found nothing.

emit() now skips findings extraction for a clean-verdict lens (the run is
still recorded). Surfaced by grading the dogfood reviews: a large share
of "false positives" were exactly these clean-verification bullets.

Added TestEmit_SkipsCleanVerdictLens; README telemetry section updated.
gofmt clean, go vet quiet, go test -race green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -350,9 +350,13 @@ context (`GADFLY_REPO`, `GADFLY_PR`) automatically.
 
 Findings are extracted heuristically from each lens's markdown — a `path:line`
 reference anchors a finding, titled by the nearest preceding heading / numbered
-item / bold lead-in. The emit is strictly best-effort: a short (~10s) timeout,
-any error (or a non-2xx response) is logged to stderr only, and it **never**
-changes the review output or the exit code.
+item / bold lead-in. A lens whose verdict is **"No material issues found"**
+emits **no** findings: its `path:line` references are verification notes
+("verified X is safe"), not problems, so extracting them would record false
+positives and unfairly penalize thorough clean-pass reviewers. The emit is
+strictly best-effort: a short (~10s) timeout, any error (or a non-2xx response)
+is logged to stderr only, and it **never** changes the review output or the exit
+code.
 
 ## Building locally