go-version-file does not parse .mod files other than go.mod

Description

When using go-version-file with a .mod file that is not literally named go.mod (e.g., golangci-lint.mod, tools.mod), the parseGoVersionFile function fails to extract the Go version correctly.

This is because the current implementation checks path.basename(versionFilePath) === 'go.mod', which only matches files named exactly go.mod. Any other .mod file falls through to the default case, which returns the entire file contents as the version string — causing version resolution to fail.

Use Case

A common Go community pattern is to use dedicated module files for tool dependencies. For example, golangci-lint recommends using a separate golangci-lint.mod file to pin the linter version independently from the project's go.mod.

Users should be able to use these files with go-version-file to install the correct Go version:

- uses: actions/setup-go@v6
  with:
    go-version-file: golangci-lint.mod

Current Behavior

parseGoVersionFile only recognizes:

• go.mod (exact basename match)
• go.work (exact basename match)
• .tool-versions (exact basename match)

Any .mod file with a different name (e.g., golangci-lint.mod, tools.mod) is not parsed as a Go module file.

Expected Behavior

Any file ending in .mod should be parsed using the same Go module file logic (extracting toolchain or go directives), not just files named exactly go.mod.

Proposed Fix

Change the condition from:

path.basename(versionFilePath) === 'go.mod'

to:

versionFilePath.endsWith('.mod')

[!Note]
Responses generated with Claude

Start at parseGoVersionFile, especially the basename check described in the issue. Update handling so any .mod path uses Go module parsing, then verify that named module files resolve their toolchain or go directive rather than treating the full file contents as the version.