feat(ci): add workflow to promote an npm dist-tag

[TimelordUK]

Problem

Publishing under next for soak testing leaves no in-repo way to flip latest afterwards. The NPM_TOKEN lives only in the repo secret (write-only, can't be read back), so promoting a release meant running npm dist-tag add from a machine with local npm credentials — which errors with 401 Unauthorized if you don't happen to have any.

Change

Adds .github/workflows/promote-tag.yml, a workflow_dispatch job taking two inputs:

• version — the already-published version (e.g. 5.3.0)
• tag — the dist-tag to point at it (defaults to latest)

It runs npm dist-tag add against the registry using the existing NPM_TOKEN secret. No actions/checkout — dist-tag only talks to the registry, never the working tree.

Steps:

1. Setup Node 24 with registry-url (matches npm-publish.yml)
2. Verify the version is actually published — fails fast with a clear message rather than a confusing 404 from dist-tag add
3. Print dist-tags before
4. npm dist-tag add, guarding against an unset secret
5. Print dist-tags after
6. Step summary

Why it's worth having beyond the immediate 401

This is also the release rollback lever. Unpublishing is only possible within 72 hours, but re-pointing latest at the previous version works indefinitely — so if a release turns out bad a week later, this is the fix.

Note for whoever runs it first

If the NPM_TOKEN secret is a granular token, check it has write permission on msnodesqlv8 and hasn't expired — granular tokens default to a 30-day life. A classic Automation token has no expiry and bypasses 2FA. A 401 at the promote step means the token, not the command.

🤖 Generated with Claude Code