fix(health): rules that fired in the wrong language, and files never scanned at all #5614

Two opposite defects, found the same day by two independent engines. The fixes depend on each other, which is why they ship together.

False positives — a rule fired where its syntax cannot exist

Vapron opened all 15 new high findings. All 15 were false.

Only the first is fixable without dataflow — and it's the same defect as the credential rule reading CELITECH_TOKEN_URL and flagging a URL: match a token, infer a meaning the surrounding language does not support.

Rules whose syntax is language-bound now declare appliesTo. Credentials, AWS keys, private keys and security TODOs stay unconstrained — they can appear in any file.

The other nine stay, and they're honest limits. One deserves quoting: a CREATE ROLE ... PASSWORD '${password}' interpolation is safe because generatePgPassword() returns hex, and the author's comment says "a hex alphabet has no quote to escape in the first place." A rule cannot see that and shouldn't pretend to — same shape as pct() being provably numeric.

False negative — documentation and config files were never scanned

The eligible set was source extensions only. Verified before fixing:

README.md        scanned=False
docs/setup.md    scanned=False
infra/main.tf    scanned=False
config.toml      scanned=False
app.ini          scanned=False

So a live key pasted into a README was invisible to every rule — including the ones that matter most there.

GateTest found the identical .md gap in its own secrets module within hours, and only because it planted a real key as a positive control while building our five false positives as fixtures. Its module was silent on all five and it nearly reported that as a clean win; the control showed it was equally silent on a real key in the same file type. A favourable cross-engine comparison was concealing a false negative.

Widening the file set is only safe because syntax-bound rules now declare where they apply.

Saturation disclosed

Criticals cost 25 each, uncapped — deliberately, so forty leaked secrets can't hide behind four. Measured consequence:

6 → 0    4 → 0    2 → 0    1 → 15    0 → 40

Any repo with 4+ criticals scores exactly 0 and the number stops moving, so security.score is a three-state indicator wearing a 0–100 label. This bit me directly: I predicted a real repo's score would return to "roughly 80" after removing three false criticals. It stayed 0 — it could not have moved.

The uncapped design is right and is unchanged. scoreSaturated now says when the number has stopped being a measurement, so a caller reads findings.bySeverity instead. Tested by tying the flag to the score actually being 0, so the two cannot drift.

Our own gate caught my test fixture

The push-time secret scanner rejected the first push: possible Private Key (PEM) in security-rule-scope.test.ts:69. Correct call. A scanner's fixtures are no more entitled to commit a key pattern than anyone else's code, and clicking past would train the repo to wave through exactly what the rule exists to catch. Assembled at runtime instead. (GateTest hit the identical rejection from GitHub push protection the same day and resolved it the same way.)

Verification

• 12 new scope tests asserting both directions — a rule must not fire in the wrong language, and language-agnostic rules must fire in docs/config.
• 4 saturation tests, one tying the flag to the score being 0.
• Full CI-safe suite: 5,375 pass, 11 fail — identical to the pre-change baseline.