fix(ci): pin pnpm and strip v prefix in sync-version job

[Siumauricio]

The sync-version job has failed on every release since v0.29.5, so mcp/cli/sdk never got version bumps and nothing was published to npm since May (sdk/cli stuck at 0.29.4, mcp at 0.29.3).

Two causes:

• npm install -g pnpm installs latest (pnpm 11), which turns the esbuild ignored-build-scripts warning into a fatal ERR_PNPM_IGNORED_BUILDS (exit 1) on the MCP step, killing the job before the CLI/SDK steps run. Replaced with pnpm/action-setup@v4 pinned to 10.22.0, matching the repo's packageManager.
• Since v0.29.5 the dokploy package.json version carries a v prefix (v0.29.14), which the job copied verbatim into the npm packages' package.json — invalid npm semver, and their publish workflows would produce vv* tags. New npm_version output strips the prefix; the dokploy release tag keeps its current format.

Verified locally: pnpm 11 reproduces the exact CI failure on the mcp repo; with pnpm 10.22.0 the full MCP step (install + fetch-openapi + generate) passes clean.

Greptile Summary

The PR repairs downstream package synchronization by installing the repository-aligned pnpm version and separating the v-prefixed Dokploy release version from the bare npm package version.

• Adds an npm_version job output that strips the leading v for MCP, CLI, and SDK package metadata.
• Replaces repeated global pnpm installation with pnpm/action-setup configured for pnpm 10.22.0.
• Updates downstream commit messages and status output to use the normalized npm version.

Confidence Score: 4/5

The PR appears safe to merge, with one non-blocking supply-chain hardening opportunity in the newly added action reference.

The version normalization and pnpm setup align with the current release format and repository package-manager version; the remaining concern is that the new third-party action can change without a reviewed workflow update because it is not pinned to an immutable commit.

Files Needing Attention: .github/workflows/dokploy.yml

Security Review

The new package-manager setup action uses a mutable third-party action tag. Pinning it to the corresponding full commit SHA would harden the release job against upstream tag replacement.

_{Reviews (1): Last reviewed commit: "fix(ci): pin pnpm and strip v prefix in ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

Mutable release action reference

pnpm/action-setup@v4 uses a mutable third-party tag in a release job that later handles DOCS_SYNC_TOKEN and pushes to three downstream repositories. Pinning the action to its full commit SHA prevents upstream tag replacement from silently changing the code executed by this job.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!