When version is specified (e.g., version: 10) or packageManager is set in package.json (e.g., pnpm@10.28.1), the action installs the correct version via pnpm self-update but the bootstrap binary takes precedence on PATH.

Root cause

self-update installs the target version and links its binary to PNPM_HOME/bin/pnpm. But the bootstrap binary remains at PNPM_HOME/pnpm. Because addPath(pnpmHome) is called after addPath(pnpmHome/bin), the bootstrap directory has higher PATH precedence and shadows the self-updated binary.

PNPM_HOME/pnpm        -> 11.0.0-rc.0  (bootstrap, higher PATH priority)
PNPM_HOME/bin/pnpm    -> 10.33.0      (self-updated, shadowed)

Swapping the addPath call order so PNPM_HOME/bin is added last (highest priority) fixes it. The bootstrap pnpm is always invoked via absolute path, so the reorder doesn't affect the bootstrap step.

Second issue: packageManager field

When packageManager: "pnpm@10.28.1" is set, readTargetVersion() returns undefined, skipping self-update entirely. The bootstrap v11 runs against the user's project and can modify the lockfile format.

The fix: extract the version from the packageManager field and pass it to self-update explicitly.

Reproduction

- uses: pnpm/action-setup@v6
  with:
    version: 10
# pnpm --version returns 11.0.0-rc.0

Reproduced locally by simulating the action flow. Swapping PATH order makes pnpm --version return 10.33.0.

Related: #225, #227, #228