Publish false-positive methodology and per-rule precision numbers

[peaktwilight]

Problem

Today the only published validation is Semgrep parity (`tests/semgrep_parity.rs`): "foxguard finds what Semgrep finds on this fixed corpus." That is a correctness check against another tool, not a measurement of precision against real code. There is no public FP rate, no labeled corpus, and no per-rule numbers.

Users evaluating the scanner need to know: for rule X, out of N findings on real code, how many are true positives?

Proposed approach

1. Labeled corpus. Assemble a small set of real OSS repos (pinned by SHA). For each rule that fires, label each finding TP / FP / unsure, with a one-line justification. Store as JSON alongside the corpus.
2. Methodology doc. Write `docs/false-positive-methodology.md` explaining corpus selection, labeling criteria, and how to reproduce.
3. Per-rule precision table. Generate a table of `rule_id | findings | TP | FP | precision` from the labeled data. Publish in the docs site and link from README.
4. Regression harness. Re-run labeling (or at least finding counts) in CI so precision doesn't silently regress when rules change.

Non-goals

• Recall measurement (needs ground-truth vuln datasets; separate effort).
• Benchmarking against Semgrep/CodeQL on precision — we can't publish their rules' numbers.

Acceptance

• First version of the labeled corpus committed under `benchmarks/precision/`.
• Methodology doc merged.
• Per-rule precision table published for at least the top 20 most-triggered rules.

[peaktwilight]

Deferring for now — this one needs a labeled corpus and careful manual TP/FP judgment, which is the kind of work that benefits from more eyes than a single maintainer pass. Leaving it open with help wanted: if someone wants to take a first cut at the methodology doc, or label findings for even one language, that's a great contribution.

Starter scope suggestion if anyone picks it up:

• Methodology doc under docs/false-positive-methodology.md describing how you'd label
• Pick 2–3 pinned OSS repos (by SHA)
• Label findings for one language only (Python is the most interesting right now, since Resolve Python import aliases before matching sensitive call names #7 just tightened its rules)
• Per-rule precision table as a first artifact

The full acceptance criteria in the issue body are the north star, but we don't need to land them all at once. Happy to review in small chunks.

[peaktwilight]

Done in the PR referenced above.