fix(review): reduce false positives in the gate's hard-blocking secret scan

[JSONbored]

Problem

The gate's deterministic hard-blocking secret scanner (generic_secret_assignment rule) flagged PR #3036 as containing a leaked secret, blocking auto-merge and forcing manual review. Independent verification found no secret-shaped content anywhere in the diff:

• A full-diff grep for secret|token|password|apikey|api_key|bearer|credential|auth — zero matches.
• A search for generic variable = "long-string" assignment patterns — zero matches.
• The PR's two touched files (src/queue/processors.ts, src/github/backfill.ts, plus their test files) contain no occurrence of common mock-token fixture literals like "installation-token" (used 351 times elsewhere in the test suite as an established, non-secret mock string).

This is very likely a false positive, but the exact trigger couldn't be pinned down from the GitHub API/review comment alone (the comment doesn't surface a file:line for this specific finding, unlike the AI reviewer's own nits).

Prior related work

• fix(review): widen the gate's hard-blocking secret scan to match REES's richer ruleset #2553 (closed) widened the scan's coverage to match REES's richer ruleset — this made the scanner catch more, which may have increased the false-positive surface.
• feat(enrichment): gitleaks-grade secret scan analyzer with value redaction #1476 (closed) added the gitleaks-grade analyzer with value redaction.
• fix(enrichment): join adjacent added lines before secret-scan matching to catch cross-line-split secrets #2454 (closed) fixed a cross-line-split secret-matching gap.

All prior work improved recall (catching more real secrets). This issue is about precision (not blocking clean PRs) — a gap not yet tracked.

Requirements

• Investigate why generic_secret_assignment fired on PR fix(review): key the durable CI-state cache on resolved required contexts #3036's diff with no visible secret-shaped content — likely candidates: scanning full file content instead of just the diff hunk, or a rule matching on variable/property naming alone (e.g. any property named key/token/secret regardless of assigned value shape).
• Surface the exact matched file:line and matched pattern in the review comment for hard-blocking secret findings, the same way the AI reviewer's nits already do — an unlocatable blocker is unactionable and forces a manual audit of the whole diff.
• Consider an owner/maintainer override path for a confirmed false positive that doesn't require bypassing the gate outside its own review flow (e.g. an explicit "confirmed not a secret" acknowledgment that unblocks without disabling the check for future PRs).

Expected outcome

Fewer manual-review holds on clean PRs from this specific rule, and when it does fire, enough detail in the review comment to verify or dismiss the finding without re-deriving it from scratch.

[linear-code]

JSO-2584

[JSONbored]

Fixed in #3178 (precision exclusion for lowercase-hyphenated fixture-shaped values + file:line locations surfaced in the finding). The third requirement (an owner/maintainer override/acknowledgment path for a confirmed false positive) is deferred — it's a separate, larger design decision (a new override mechanism) and the issue itself only "considers" it; not built in this PR.