The avoid_ref check read HEAD's tags via `git for-each-ref` with no --git-dir,
so it inspected the caller's checkout instead of the installed clone.
Whether it passed then depended on which ref triggered the workflow
(the same commit passed when built as the v0.40.6 tag but failed when built as master, since only the former had the tag present),
not on the install result.
Query the installed clone and compare commits,
so a HEAD that is legitimately the latest release commit
(eg master right after a release)
is exempted deterministically.
The test's `rm -rf "$NVM_DIR"` intermittently failed with
`rm: cannot remove...: Directory not empty`
and aborted under `set -e`.
Cause: after the clone/fetch, git can spawn a detached background gc/maintenance process that keeps writing into the clone dir while `rm -rf` runs (a concurrent writer makes the final rmdir fail).
It is not egress- or version-related
(it reproduces with all endpoints allowed),
and it is environment-timing dependent
(recently became consistent on the GitHub runners).
Disable git's background work for the test (gc.autoDetach / maintenance.auto)
so all git operations finish synchronously, and retry the rm once as a safety net.
`[ "${head_ref}" != "${avoid_ref}"]` is missing the space before the closing bracket,
so the shell prints `[: missing ']'` and the avoid_ref assertion never actually runs
(it is inside an `if` condition, so the error was non-fatal and silently disabled the check)