fix(leak-scan): repair four rules that could never fire

[ExtraToast]

Summary

The deny-list matches with grep -E, but every test asserts against Python's re. Those engines disagree silently, so patterns using Perl-only syntax passed the whole suite while matching nothing in production.

Same pattern, same input 10.42.0.0/16:

engine	result
Python re (what the tests use)	matches
GNU grep -E (what actually runs)	0 matches

Four separate defects, all of which meant a rule reported clean when it should have fired:

1. ssh_keys — private keys were undetectable. -----BEGIN .* PRIVATE KEY----- begins with -, so grep parsed it as an option and exited with a usage error visible in every run:

grep: unrecognized option '-----BEGIN .* PRIVATE KEY-----'

A private key added in a diff scanned clean. Both call sites now pass patterns with -e.

2. Perl-only syntax in six patterns. \d and (?:...) are meaningless in POSIX ERE:

category	was	effect
ipv4_literal	\d{1,3}	entirely dead
ipv6_literal	(?:...)	both patterns dead; source of the ? at start of expression warnings
cgnat	[7-9]\d, 1[01]\d	100.70–119 undetected
rfc1918	2\d	172.20–29 undetected

3. EXCLUDE_PATHS was wired into every mode except the one it documents. The input says "Only effective in pr-diff mode", but run_diff_deny_list_scan never read it — callers passing exclude-paths to suppress a known false-positive class got no exclusion at all. Now applied to the added-line scan, using the same literal-prefix semantics as the path scan.

4. The exclusion counter crashed the scan. Found while fixing 3. grep -c . prints 0 and exits 1 on no match, so || echo 0 appended a second zero and the arithmetic saw 1 - 0\n0:

run.sh: line 305: 1 - 0
0 : syntax error in expression

Excluding every changed file didn't skip the scan, it crashed it — a docs-only PR in a repo passing exclude-paths would have failed on a shell syntax error.

Validation

The new test module shells out to grep, not re — that engine divergence is the actual defect class, and no amount of Python-side testing would have caught any of this.

• Verified the new test fails against the previous patterns before it passed against these: 6 subtest failures, one per dead pattern.
• Full suite: 116 passed, 228 subtests, no regressions.
• End-to-end against the real run.sh with gitleaks installed, GNU grep, linux/amd64:

scenario	expected	result
private key in diff	fail	fails (was: passed clean)
IPv4 literal in diff	fail	fails (was: passed clean)
IPv4 literal in an excluded path	pass	passes (was: crashed)
clean diff	pass	passes

Risk

The IP rules going live is the real behavioural change here, so I measured it rather than guessing. Over the last 17 commits on fleet-infra main, deny-list hits on added lines:

0 would have been blocked under the old patterns, and 0 under the new ones.

Repos that legitimately carry subnet literals now have a working valve for the first time, since exclude-paths actually functions.

Consumers pin by tag (fleet-infra is on @v0.12.9), so nothing changes for anyone until they bump — this cannot surprise a repo mid-flight.

Links

• Found while investigating a false positive on JorisJonkers-dev/fleet-infra#167, where two lines of standard RFC1918 except: boilerplate in a NetworkPolicy block the required check.