ci: allowlist gitleaks false positives blocking secret scan

[ohdearquant]

The generic-api-key rule flags the ADR-101 section heading token wasm32-compilable (in history on main, so every PR branched from current main fails the Secret scan check) and two hex test fixtures in khive-pack-git cache tests. Adds a .gitleaks.toml extending the default config with an allowlist for the three matched strings. Verified locally: gitleaks detect goes from 4 findings to 0 with real detection rules unchanged.

🤖 Generated with Claude Code

[ohdearquant]

Codex review (round 2, cumulative): APPROVE at head a98a3af. Findings: 0 Blocker, 0 High, 0 Medium, 0 Low.

Round 1 (APPROVE-WITH-FIXES) raised one High: the original global unanchored allowlist regexes were tested against the extracted secret, so a real generic-api-key value that happened to contain an allowlisted substring would be suppressed repository-wide. Round 2 verifies the rework: the broad allowlist is replaced by a .gitleaksignore carrying the four exact finding fingerprints (commit:path:rule:line) for the confirmed non-credentials — two hex cache-lock test fixtures in crates/khive-pack-git/src/cache.rs and two documentation lines in docs/adr/ADR-101-kg-changeset-model.md. Each ignore is scoped to one commit, path, rule, and line, so no real future secret can be suppressed by substring coincidence. The default gitleaks rule set and the full-history CI scan are preserved.

Verified locally against full history (1584 commits, gitleaks 8.30.1): four findings without the file, zero with it, exit 0. The pinned CI Secret scan (gitleaks) check passes on this branch.