Add gitleaks secret-scan CI

[DjamilaBaroudi]

Adds a gitleaks secret-scan workflow that runs on push and PRs, gated by a committed baseline of existing findings (docs/test fixtures). Standardizes the secret-in-code control across repos for SOC 2.

Pinned to gitleaks v8.30.1. Baseline entries are docs examples and _test.go fixtures — no live secrets.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
.github/workflows/secrets-scan.yml:16
**Docker image pinned to mutable tag, not digest**

`ghcr.io/gitleaks/gitleaks:v8.30.1` uses a semver tag, which can be overwritten on the registry at any time. For a security-scanning step this creates a supply-chain risk: a compromised or repointed tag would silently replace the scanner with untrusted code. Pin to the image digest instead, e.g. `ghcr.io/gitleaks/gitleaks:v8.30.1@sha256:<digest>`.

### Issue 2 of 2
.github/workflows/secrets-scan.yml:14-16
**`dir` mode skips git history; `fetch-depth: 0` is unused overhead**

The `dir` subcommand scans only the files present in the working tree. Any secret committed to a prior commit and then removed (or never appearing in the final tree state) will not be detected, even though `fetch-depth: 0` fetches the complete history. For SOC 2 coverage, the `git` subcommand (or `detect --source .`) scans every commit in range and would catch secrets that existed even briefly. If `dir` mode is intentional (simpler baseline management), `fetch-depth: 0` can be dropped to `fetch-depth: 1` to avoid cloning the full history needlessly.

_{Reviews (1): Last reviewed commit: "ci: add gitleaks secret-scan workflow" | Re-trigger Greptile}

[greptile-apps]

Docker image pinned to mutable tag, not digest

ghcr.io/gitleaks/gitleaks:v8.30.1 uses a semver tag, which can be overwritten on the registry at any time. For a security-scanning step this creates a supply-chain risk: a compromised or repointed tag would silently replace the scanner with untrusted code. Pin to the image digest instead, e.g. ghcr.io/gitleaks/gitleaks:v8.30.1@sha256:<digest>.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/secrets-scan.yml
Line: 16

Comment:
**Docker image pinned to mutable tag, not digest**

`ghcr.io/gitleaks/gitleaks:v8.30.1` uses a semver tag, which can be overwritten on the registry at any time. For a security-scanning step this creates a supply-chain risk: a compromised or repointed tag would silently replace the scanner with untrusted code. Pin to the image digest instead, e.g. `ghcr.io/gitleaks/gitleaks:v8.30.1@sha256:<digest>`.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

dir mode skips git history; fetch-depth: 0 is unused overhead

The dir subcommand scans only the files present in the working tree. Any secret committed to a prior commit and then removed (or never appearing in the final tree state) will not be detected, even though fetch-depth: 0 fetches the complete history. For SOC 2 coverage, the git subcommand (or detect --source .) scans every commit in range and would catch secrets that existed even briefly. If dir mode is intentional (simpler baseline management), fetch-depth: 0 can be dropped to fetch-depth: 1 to avoid cloning the full history needlessly.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/secrets-scan.yml
Line: 14-16

Comment:
**`dir` mode skips git history; `fetch-depth: 0` is unused overhead**

The `dir` subcommand scans only the files present in the working tree. Any secret committed to a prior commit and then removed (or never appearing in the final tree state) will not be detected, even though `fetch-depth: 0` fetches the complete history. For SOC 2 coverage, the `git` subcommand (or `detect --source .`) scans every commit in range and would catch secrets that existed even briefly. If `dir` mode is intentional (simpler baseline management), `fetch-depth: 0` can be dropped to `fetch-depth: 1` to avoid cloning the full history needlessly.

How can I resolve this? If you propose a fix, please make it concise.