## Summary
- Export `pnpm_config_pm_on_fail=download` from the action so the bootstrap pnpm switches versions via `manage-package-manager-versions` instead of throwing `BAD_PM_VERSION` when a project pins `devEngines.packageManager.onFail = "error"` without supplying a `version:` input.
- Adds a `test_dev_engines_on_fail_error` workflow job (Linux/macOS/Windows, exact + range) that reproduces #252.

Fixes #252.

)

* fix: self-update bootstrap to packageManager-pinned version (#233)

When package.json pins pnpm via `packageManager` or an exact
`devEngines.packageManager.version`, self-update the bootstrap up
front. The bootstrap's `pnpm store path` skips pnpm's auto-switch
(the `store` command sets `skipPackageManagerCheck = true`), so it
reports the bootstrap's `STORE_VERSION` while the user's actual
install runs under the pinned version and writes to a different
STORE_VERSION — breaking `cache: true` and `setup-node`'s
`cache: pnpm` on cold caches.

* fix: check bin/ dir instead of pnpm.exe for self-update detection

On Windows pnpm self-update writes `.bin/bin/pnpm` (a JS launcher),
not `.bin/bin/pnpm.exe`, so the previous existsSync probe always
fell back to pnpmHome and the bin_dest output pointed at the
bootstrap pnpm. Check whether the `bin` directory itself exists.

* fix: self-update accepts ranges; drop exact-semver gate

`pnpm self-update` resolves semver ranges to a specific version, so
`devEngines.packageManager.version: ">=10 <11"` can also go through
the self-update path. That makes readTargetVersion total — it always
returns a string or throws — so the runtime auto-switch fallback (and
the `pnpm_config_pm_on_fail=download` export from #252) is no longer
reachable and gets removed.

Adds a range case to the cache_store_path matrix.