ci(release): don't let the credential pre-flight break tokenless publishing

[celikgo]

Follow-up to #3, found while trying to actually publish webmobai-mcp@1.4.1.

The bug

#3 added an npm whoami pre-flight so that a dead token reports itself as a
dead token instead of as npm's misleading 404 Not Found - PUT. That is
correct when a token exists. It is wrong when one does not.

Under trusted publishing there is no long-lived credential: the npm CLI
exchanges the Actions OIDC token for a short-lived one at publish time and
attests provenance automatically. npm whoami has nothing to answer with and
exits non-zero — so a repository configured exactly the way npm recommends
would fail the gate and never reach a publish it was ready to perform. The
step written to explain a red pipeline would have become a fresh cause of one.

The gate now returns early when NPM_TOKEN is unset and enforces whoami only
when a token is present.

Why this is urgent rather than tidy

npm restricted 2FA-bypass granular access tokens on 2026-07-31.
Creating a package and changing its access now require an interactive 2FA
challenge — and npm publish --access public against a name that has never
been published does both.

This is confirmed, not inferred. Publishing 1.4.1 with a valid Publish token
for this account:

npm error code E403
npm error 403 Forbidden - PUT https://registry.npmjs.org/webmobai-mcp
npm error 403 You may not perform that action with these credentials.

npm whoami with that same token returns celikgo, and npm profile get
also 403s. The credential authenticates and is refused for writes. Direct
publish is withdrawn from these tokens entirely in January 2027.

So the failure message no longer advises minting another token. It points at
configuring a trusted publisher and deleting the secret.

Consequence for the first publish

Trusted publishing is configured per-package in npmjs.com package settings,
which requires the package to exist. webmobai-mcp has never been published,
so v1.4.1's first publish has to happen interactively with a 2FA challenge;
trusted publishing can take over from the next release.

The Is this version already on the registry? gate from #3 makes that sequence
work without any special-casing: once 1.4.1 exists, the tag's publish job
detects it, skips the publish, and verify-npm still proves both documented
install paths from a clean runner.

Verification

Both branches of the gate exercised directly, plus YAML and bash -n over
every run: block in the file.