Release v1.4.1: make the documented install paths real, and stop the pipeline lying about why it failed

[celikgo]

The Actions tab has shown red since 2026-07-17 and two of the four install
paths the README teaches have never worked. Both have the same root cause.

What was actually wrong

The v1.4.0 Release run failed on npm publish:

npm error 404 Not Found - PUT https://registry.npmjs.org/webmobai-mcp
npm error 404  'webmobai-mcp@1.4.0' is not in this registry.

That reads as a misnamed package. It was not. The registry answers an
unauthenticated or under-scoped request to create a package with 404
rather than 401, on purpose, so a token cannot be used to enumerate names —
so an expired NPM_TOKEN and a typo in name produce byte-identical logs.
The credential was the cause: the secret was minted 2026-04-12, the run was
2026-07-17.

Because the publish never landed, npm install -g webmobai-mcp and the
npx -y webmobai-mcp invocation in the Claude Desktop / Claude Code MCP config
have both 404'd for every reader since. The MCP path is the one that
demonstrates the AI-native design, and it was the one that did not resolve.

The packaging itself was never broken — mcp-server/package.json already
declared the name, main, and all seven bin entries, and a local
npm publish --dry-run produces a clean 203-file tarball with every binary
resolving.

Changes

release.yml

• Is this version already on the registry? runs before anything needing a
  credential. Publishing nothing requires no permission to do it, and demanding
  a valid token in order to then decide there is nothing to do is how a green
  release turns red.
• npm credentials are valid runs npm whoami and fails with the token named
  as the cause and the page to fix it on, instead of the 404 folklore above.
• Publish to npm is now skipped when the version is already up. npm versions
  are immutable, so re-running a shipped release was a guaranteed E403.
• verify-npm is a new job with no actions/checkout. Every other job
  tests the working copy; this one tests what a stranger receives. It resolves
  the version from the registry, runs npx -y webmobai-mcp --help, does the
  README's global install, runs webmobai-doctor, and asserts all seven
  binaries reach PATH. A file present on the runner but missing from files in
  package.json now fails CI rather than failing a reader.

docs-links.yml — the npmjs.com exclusion was justified by a readme-claims
job in ci.yml that does not exist under that name and never touched the
registry. The exclusion is fine; the justification was not. It now points at
verify-npm, which actually does the thing.

v1.4.1 — a distribution release, no functional change. v1.4.0's tag is
public and its release already carries four macOS assets, so re-pointing it
would rewrite history to fix what a patch version fixes cleanly. Version bumped
in lockstep across package.json, mcp-server/package.json, both lockfiles,
tauri.conf.json, Cargo.toml, Cargo.lock, and server.json (twice), which
is what the existing Tag and package version agree gate checks.

Also landing with this tag

The release matrix already gained ubuntu-22.04 and windows-latest after the
failed run, so v1.4.1 is the first tag that ships .AppImage/.deb and
.msi/.exe alongside the macOS .dmg. All five previous releases were
macOS-only.

Verification

• scripts/check-doc-claims.mjs: 21 claims across 3 files still match — 51
  tools, 7 binaries, 219 tests.
• npm publish --dry-run: clean tarball, all seven bin targets resolve.
• node dist/index.js --help / --version: pass, and report 1.4.1.
• Every run: block in both workflows parses under bash -n; both files parse
  as YAML.

Not covered here

NPM_TOKEN in repository secrets is still the dead credential. This PR makes
the failure legible and makes the job idempotent, but a valid token is required
before Actions can publish on its own.