fix(dev): fall back to PATH tools when Hermit shims are unusable

[sumit-m]

Summary

Falls back to a PATH-resolved tool when a Hermit shim in bin/ is not executable.

Hermit's bin/ entries are git symlinks. On Windows they are checked out as plain text files whenever core.symlinks is false — which is the default without Developer Mode or an elevated shell — so "${REPO_ROOT}/bin/just" fails with exit 127. Hermit has no Windows build, so there is nothing to repair locally; the tools are simply installed on PATH instead.

scripts/dev-setup.sh and scripts/run-tests.sh now route their Hermit invocations through a small helper:

hermit_tool() {
  local tool="$1"
  if [[ -x "${REPO_ROOT}/bin/${tool}" ]]; then
    printf '%s' "${REPO_ROOT}/bin/${tool}"
  else
    printf '%s' "${tool}"
  fi
}

The -x test means every Hermit-enabled host keeps using the pinned shim exactly as before. Only a host where the shim is not executable takes the PATH path.

lefthook install is also guarded rather than assumed, with a warning pointing at the install docs, since it is not a hard requirement to run the suite.

Related issue

Part of #2388 (Windows Support).

No duplicate found: 11 open PRs touch scripts/run-tests.sh or scripts/dev-setup.sh, but none add hermit or PATH-fallback handling. Checked by intersecting changed-file paths across all open PRs.

Testing

Verified on Windows 11 (x86_64-pc-windows-msvc, Git Bash):

• Before: scripts/dev-setup.sh exits 127 at "${REPO_ROOT}/bin/just" — bin/just is a 19-byte text file containing the symlink target, not an executable.
• After: it resolves just from PATH and completes.
• scripts/run-tests.sh likewise reaches the test run instead of failing at tool resolution.
• bash -n clean on both scripts.

Not verified on macOS or Linux — I have no such hardware. On any host where Hermit's shims are real symlinks the -x test succeeds and the resolved path is byte-identical to today's, so the change is inert there by construction.

Worth flagging: this makes the scripts run on Windows, but it means those runs use whatever tool versions are on PATH rather than Hermit's pinned ones. That seemed better than not running at all, though I would understand a maintainer preferring an explicit warning when the fallback fires.

[Chessing234]

Practical Windows/Hermit fix. Checking -x on bin/<tool> before falling back to PATH correctly handles the "symlink checked out as a text file" case without needing Developer Mode. Duplicating hermit_tool into both scripts is fine for now; if a third script needs it, consider a tiny scripts/lib/hermit.sh. The lefthook soft-skip is the right call when the shim isn't runnable. LGTM.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 4cd82f513214aad11c2b742ce7cc7c681e8e32a0...958fc29cd4033753281545fc3978c194fb98dc72.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 958fc29cd4033753281545fc3978c194fb98dc72 to authorize a new review.
Any previous review applies only to its recorded range.