chore(ci): list both fingerprint forms so .gitleaksignore works on any gitleaks

[Gerrrt]

make validate failed on the developer machine and passed in CI, for nine
findings this file already documents:

FAIL  gitleaks (full history)      leaks found: 9

Cause

A gitleaks fingerprint is <commit>:<path>:<rule>:<line>, matched as a literal
string. Up to v8.25 the commit is the full 40-char SHA; from v8.26 it is the
7-char short form. Path, rule and line are byte-identical across the change —
only the SHA length moved:

in this file (written by 8.24.0)   ee3d443abc19029f182edbcf9beadb3e6ca8f7c5:…:4
emitted by a local 8.30.1          ee3d443:…:4

CI pins zricethezav/gitleaks:v8.24.0; brew install gitleaks is years ahead of
that. One form can only ever satisfy one of the two.

Why it matters

This is the precise failure the file exists to prevent. Its own header says a
scan "that is red for a known reason gets ignored, and then a new leak goes
unnoticed too" — and a permanently red make validate trains exactly that
habit, on the machine where a developer is most likely to introduce a leak.

Fix

List both forms. An entry matching no finding is inert, so the full-SHA lines
stay correct for CI and the short-SHA lines cover 8.26+. A third form can be
appended if the format moves again.

Rejected alternatives: pinning gitleaks locally fixes one machine and a brew upgrade silently undoes it; regenerating for 8.26+ inverts the problem and
breaks CI.

Verification

With the local 8.30.1:

• gitleaks detect --log-opts=--all → 0 findings
• ./scripts/validate.sh → all checks passed
• not over-broad: a decoy private key dropped into the working tree is still
  detected, so the additions suppress only the nine known findings

The full-SHA half is exercised by CI on this PR — a green Secret scan here is
what confirms v8.24.0 is unaffected.

After the history purge (docs/runbooks/purge-git-history.md) this file goes
away and the duplication with it.

🤖 Generated with Claude Code