fix(review): add post-LLM filter for hardcoded secret false positives

[ajianaz]

Problem

Cora LLM sometimes flags struct field declarations like api_key: String or api_key: extract_api_key.clone() as "Hardcoded password or secret in variable" — even though no literal value is present.

The .cora.yaml rules field is only LLM context (non-deterministic), so instructions to ignore these are unreliable.

Solution

1. Post-LLM false positive filter

Add apply_llm_secret_fp_filter — a deterministic post-LLM filter that:

1. Identifies LLM findings with issue_type: security and titles matching hardcoded secret keywords
2. Looks up the actual added line at the reported file:line in the parsed diff
3. Cross-validates against the sec-hardcoded-secret regex (key = "literal")
4. Removes findings where the line is just a struct field declaration (no literal assignment)
5. Keeps findings for unknown/unresolvable lines (safe default — better safe than sorry)

Pipeline position:

LLM findings
  → valid file path filter (existing)
  → apply_llm_secret_fp_filter (NEW)
  → apply_ignore_rules (existing)
  → min_severity block check (existing)

2. Dependency security fixes

• Bump git2 0.20 → 0.21 (resolves RUSTSEC-2026-0183, RUSTSEC-2026-0184)
• Bump quinn-proto 0.11.14 → 0.11.15 (resolves RUSTSEC-2026-0185)

Testing

4 unit tests for the FP filter:

• ✅ Struct field declarations → removed (FP)
• ✅ Actual hardcoded secret → kept (real finding)
• ✅ Non-security findings → pass through
• ✅ Unknown lines → kept (safe default)

All 596 tests pass. Clippy clean. Fmt clean.