.gitleaksignore fingerprint (file:rule:line) matches by position, not secret content

Repro:

1. Commit config.py with a secret (AWS key A) on line 1.
2. 1. gitleaks detect -> reports it, prints the fingerprint (file:rule-id:start-line).
3. 1. Add that fingerprint to .gitleaksignore.
4. 1. gitleaks detect -> no leaks (correctly suppressed).
5. 1. Replace secret A with a completely different, unrelated secret B on the same line, commit.
6. 1. gitleaks detect -> still "no leaks found". Actual: exit 0, no leaks reported after step 6. Expected: flag that the content covered by a suppressed fingerprint changed.

Why it matters: the global fingerprint in AddFinding (detect/detect.go) is file:rule-id:start-line -- it never includes the secret value or a hash of it. A real, unrelated leak on an already-ignored line is permanently invisible to gitleaks detect, the same command meant to catch it.

Secondary, conditional finding: --baseline-path matches by exact Match/Secret content (detect/baseline.go), which is correct -- except when --redact is also passed (common in CI to avoid logging secrets in plaintext), where the content check is skipped entirely and only position+entropy remain. A same-length, same-character-multiset swap (so entropy matches) at the same position evades detection with --redact on; confirmed this does NOT happen without --redact.

Suggest: include a stable hash of the secret value in the .gitleaksignore fingerprint, not just file:rule:line. For --baseline-path --redact, hash the secret before comparing instead of dropping the content check.