ci(npm-publish): make v1.x own the latest dist-tag

[John-David Dalton (jdalton)]

v1.x is the line customers consume, so it should own the latest dist-tag — the tag an untagged npm install socket resolves to. The guard ran the other way, refusing latest from this branch and reserving it for the default branch, which carries the 2.x prerelease line.

The cost was visible on the package page. socket@latest sat on 1.1.147 for a week while 1.1.148 through 1.1.152, including a commons-io CVE bump, published under a staged side tag that no untagged install ever resolves.

What changed

The guard now compares the dispatched ref against v1.x instead of the repo's default branch, and logs the allow case so a passing run says why. The file header's step 4 said to pick a NON-latest dist-tag; it now says dist-tag=latest. The dist-tag input already defaulted to latest, so that default becomes usable rather than something the guard immediately rejects.

Dry runs are unaffected — they pass regardless of dist-tag because they upload nothing.

The matching half on the default branch

Our shared publish-workflow template now guards latest to a consumable release line rather than to the default branch, and reads which branch that is from a release.latestDistTagBranch setting in this repo's own config. It defaults to the repo's default branch, so other repos sharing that template are unaffected. socket-cli declares v1.x.

That half is already on main. This PR is the other half.

Already done manually: latest was repointed to 1.1.152 and the staged tag removed, so socket now carries a single dist-tag. Without this PR the next v1.x release would recreate staged and still refuse to move latest.

Ran: actionlint clean on the edited workflow.
Did not run: no dispatch — the publish path is unchanged apart from which ref may request latest.

---

Note

Medium Risk
Changes which branch can publish npm's latest dist-tag—a customer-facing install resolution path—but only tightens alignment with the intended release line and does not alter build/publish mechanics beyond the ref check.

Overview
Fixes the npm publish guard so dist-tag=latest is only allowed when the workflow runs from v1.x, not from the repo default branch. Untagged npm install socket resolves to latest, so the consumable 1.x line should own that tag; the previous rule blocked v1.x from publishing latest and left newer 1.x releases on side tags like staged.

The workflow header and step comments now describe this policy (2.x prerelease on default uses next/beta/canary/rc). The guard compares github.ref to refs/heads/v1.x, logs when latest is allowed, and dry runs still skip the check because nothing is uploaded.

^{Reviewed by Cursor Bugbot for commit 3eb8128. Configure here.}