Windows: --scan-secrets treats gitleaks as missing when PATH probe uses command -v

[jbetala7]

Problem

lib/gstack-memory-helpers.ts checks whether gitleaks is available with execSync("command -v gitleaks") before secretScanFile() runs the actual scan. That shells through a POSIX builtin instead of probing the executable directly. On Windows/native Bun environments, command -v is not a portable executable check, so --scan-secrets can report scanner: "missing" and skip the opt-in secret scan even when gitleaks.exe is installed on PATH.

Current behavior

• gstack-memory-ingest --scan-secrets calls secretScanFile().
• secretScanFile() first calls the shell-based command -v gitleaks check.
• If that shell check fails, gstack warns that gitleaks is missing and returns scanner: "missing" without running gitleaks detect.

Expected behavior

Probe gitleaks the same way the scanner will run it: execute the gitleaks binary directly via argument-array process APIs, and then run gitleaks detect with the explicit current environment.

Duplicate check

I searched issues/PRs for gitleaks, secretScanFile, scan-secrets Windows, gitleaks PATH, and command -v. Existing open PR #1418 touches lib/gstack-memory-helpers.ts, but it fixes gbrain doctor engine detection, not the gitleaks availability probe. Existing PR #1485 removes a similar command -v gbrain path, but does not cover gitleaks.

Candidate fix

Replace the shell-based availability check with a direct gitleaks version probe, pass process.env explicitly to the execFileSync calls, and add a regression test with a fake gitleaks binary that verifies the direct probe runs before detect.

[jbetala7]

Opened PR #1546 with the direct gitleaks probe fix: #1546