fix(ci): retry the gitleaks download in Secret Scan (transient curl-56 blocks PRs)

[cloudingenium-automation]

Fleet propagation of KH#1351. The Secret Scan gitleaks download used a bare curl -sSfL (no retry) — a transient network blip (curl exit 56, recv failure) fails the whole scan and blocks the PR even though no secret exists (witnessed on crypto-tax-core#29). Adds --retry 5 --retry-delay 3 --retry-all-errors --connect-timeout 15. The sha256sum -c verification is unchanged → supply-chain-safe.

🤖 Generated with Claude Code

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[cloudingenium-automation]

Cursor Composer-2.5 Review — Tier 1.5 (Copilot-outage second reviewer)

Relayed by the fleet-driver: the Cursor Cloud Agent's GitHub App can't post comments (addComment 403), so the bot posts the agent's verbatim review. Second reviewer per the Copilot-outage "both for max coverage" doctrine (agent bc-6a8d7fd4-81ed-45f7-82d1-c5bb5fc80318).

Verdict: APPROVE

Summary

PR #12 is a one-line CI hardening change in .github/workflows/secret-scan.yml: the pinned gitleaks tarball download gains curl retry flags (--retry 5 --retry-delay 3 --retry-all-errors --connect-timeout 15) while leaving the pinned version, fixed GitHub release URL, and sha256sum -c verification unchanged. That matches the stated goal (transient curl failures such as exit 56 should not block PRs when no secret is involved) without weakening the existing supply-chain controls documented in the workflow header (pin + SHA256 from #9/#3/#10).

Findings

No blocking findings.

Optional, low-severity notes (not required to merge):

Location	Severity	Note
.github/workflows/secret-scan.yml:48	Low (nit)	--retry-all-errors needs curl ≥ 7.71 (2020). If a self-hosted [self-hosted, Linux, Build] image ever ships an older curl, the step fails at argument parse time rather than at download. Worth a one-line comment or a quick curl --version check in runner docs if you maintain those images.
.github/workflows/secret-scan.yml:48	Low (nit)	Retries address connect/recv blips; a stalled transfer after connect is not capped (--max-time / --retry-max-time). Worst case is extra wall time until the job timeout-minutes: 5; sha256sum -c still prevents running a bad binary.
.github/workflows/secret-scan.yml:48	Info	With -f and --retry-all-errors, a bad pin (e.g. 404) retries five times before failing—slightly slower failure, still safe because verification fails.

Correctness

• Appropriate fix for the problem: --retry-all-errors is the right knob for recv/connection failures that default retry logic may not cover; bounded retries and connect timeout limit blast radius.
• Failure mode unchanged: Wrong or partial artifact still fails at sha256sum -c (line 50) before tar / gitleaks detect.
• No change to scan scope (LOG_OPTS, gitleaks.toml, fetch-depth: 0) or permissions (contents: read).

Security

• No new SSRF/injection surface: URL remains a constant GitHub releases path with env-interpolated pinned GITLEAKS_VERSION; no user-controlled input.
• Supply chain: Pin + SHA256 unchanged; retries do not skip or weaken verification.
• Secrets: Workflow does not log credentials; change is download-only.

Conventions (CLAUDE.md / .claude/rules)

• CLAUDE.md: Python/library conventions do not apply to this CI-only diff; no conflict.
• .claude/rules/: Not present in this repo (nothing to violate).
• Workflow comments: Aligns with existing hardened Secret Scan pattern (pinned gitleaks, full PR range, allowlist in gitleaks.toml).

Recommendation

Merge as-is. If you want extra resilience later, consider --max-time on the same curl line and documenting minimum curl on self-hosted runners—optional follow-ups, not blockers for this PR.