ci(secret-scan): allowlist public contract addresses in the generated address book

[SaulBuilds]

What

Adds a small, narrow .gitleaks.toml so the secret-scan merge gate stops
flagging the generated on-chain address book as a secret. Hardening /
scanner-compatibility only — no behavior change to the code.

Why (the false positive)

The default gitleaks generic-api-key rule keys off trigger words in the
contract name and reports the value beside it. In the address book:

"ModelAccessControl":     "0x…40 hex…"   <- the word "Access" trips the rule
"WebAuthnP256Validator":  "0x…40 hex…"   <- the word "Auth" trips the rule

Those values are public 40204 contract addresses (0x + 40 hex = 20 bytes),
not credentials. Nothing secret is exposed.

The fix (narrow, not blanket)

[extend]
useDefault = true

[[allowlists]]
description = "Public 40204 contract addresses (0x + 40 hex) in the generated address book are not secrets"
regexes = ['''^0x[0-9a-fA-F]{40}$''']
regexTarget = "secret"

• useDefault = true — every default rule stays on. Nothing is disabled.
• The allowlist exempts only a finding whose secret is exactly a
  0x-prefixed 40-hex EVM address. Real credentials are not 20-byte hex
  addresses, so they are still caught.

Why not a paths-scoped allowlist

The obvious "scope it to the address-book file" approach was tested and
rejected: in gitleaks 8.30.1 (the version this repo pins) an allowlist
paths match skips the whole file — even with condition = "AND" — which
would suppress any real secret that ever landed in that file. Scoping by the
address value pattern is strictly narrower.

Which workflow runs gitleaks

.github/workflows/merge-gate.yml, job secret-scan:

• line 65 — if [ -f .gitleaks.toml ]; then cfg=(--config .gitleaks.toml); fi
• line 66 — "$RUNNER_TEMP/gitleaks" git . "${cfg[@]}" --log-opts="$range" --redact --no-banner

So a .gitleaks.toml at the repo root is picked up automatically. gitleaks
version is pinned at line 40 (GL_VERSION: 8.30.1), which this PR was verified
against.

Narrowness proof (gitleaks 8.30.1, local, not committed)

1. Scan the address book with this config → no leaks found (the public
   addresses are exempt).
2. Temporarily inject four real-looking secrets into that same file — a
   Stripe key (sk_live_…), a GitHub PAT (ghp_…), a 0x-prefixed 64-hex
   private key, and a generic api_key = '…' — and rescan with this config
   → leaks found: 4. All four are still flagged (stripe-access-token,
   github-pat, generic-api-key ×2); the public addresses remain exempt.
3. Test edit reverted; nothing added to the tree but .gitleaks.toml.

Real secret still flagged after allowlist: YES.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Vv2gVzy5XLFKg48yckN9YQ

[Matr0xshka]

Reviewed the secret-scan hardening/allowlist change. The allowlist is scoped to exact public 0x + 40-hex contract-address values and does not disable default gitleaks rules or skip files. Merge remains gated on CI.

[BerryManifold]

Second-look review from BerryManifold: approved the code/content diff as submitted. Merge remains gated on required CI and branch protection.

[SaulBuilds]

Superseded: the equivalent address-only gitleaks allowlist (exact 0x+40-hex values) landed with the address-book sync. Thanks for the clearer header comments; happy to fold them in as a follow-up.