macOS: builds from source instead of downloading pre-built binaries; breaks with go.work files

Problem 1: macOS always builds from source

On Linux and Windows the action downloads pre-built binaries from pkgs.tailscale.com/stable/. On macOS it takes a different path: it clones https://github.com/tailscale/tailscale.git, checks out the requested version tag, and compiles both tailscale and tailscaled by running build_dist.sh.

Pre-built macOS binaries are available on pkgs.tailscale.com/stable/ — the API response includes a MacZips field with links to universal .zip and .pkg files for every stable release. For example, for the default version 1.94.2:

• https://pkgs.tailscale.com/stable/Tailscale-1.94.2-macos.zip (25.9 MB)
• https://pkgs.tailscale.com/stable/Tailscale-1.94.2-macos.pkg (18.3 MB)

The action could download and extract these just as it does for Linux (.tgz) and Windows (.msi).

Impact: Compiling from source requires cloning the entire Tailscale repository and running a full Go build on every CI run that has a cold cache. This is significantly slower than downloading a pre-built binary.

If there is a reason macOS must build from source (e.g. code signing requirements, entitlements, notarization), that reason should be clearly documented in the README.

Problem 2: Source build breaks when the host repo has a go.work file

When the action runs on a macOS runner inside a checked-out repository that contains a go.work file, the source build fails with:

directory cmd/mkversion is contained in a module that is not one of the workspace modules listed in go.work. You can add the module to the workspace using:
	go work use .
/path/to/tailscale/build_dist.sh: line 32: VERSION_LONG: unbound variable

What happens: The action clones the Tailscale repository into the runner's working directory (typically a subdirectory of the host repo). When build_dist.sh runs go run ./cmd/mkversion, Go's workspace mode walks up the directory tree, finds the host repo's go.work file, and rejects the build because cmd/mkversion is not listed as a workspace module. Because build_dist.sh runs with set -u, the unbound VERSION_LONG variable then causes a hard abort.

Real-world failure: This broke CI in a consumer repo that uses a go.work file:
https://github.com/trivago/metafold/actions/runs/24346366481/job/71088404471

Workaround: Setting GOWORK=off in the environment before the action runs disables Go workspace mode and unblocks the build:

- uses: tailscale/github-action@v4
  env:
    GOWORK: 'off'

This workaround is not documented anywhere. The README makes no mention of the always-build-on-macOS behavior or its interaction with Go workspaces.

Requested changes

Either:

(a) Preferred: Download pre-built macOS binaries from pkgs.tailscale.com/stable/ instead of compiling from source, consistent with the Linux and Windows code paths.

(b) Alternative: If compiling from source on macOS is intentional and unavoidable, add the following to the README:

• A note explaining that macOS always compiles Tailscale from source and why.
• A note that the action must be run before checking out any repository that has a go.work file, or that GOWORK=off must be set in the environment before invoking the action.