chore(deps): update pnpm to v11.5.2 (#1952)

This PR contains the following updates:

| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|
| [pnpm](https://pnpm.io)
([source](https://redirect.github.com/pnpm/pnpm/tree/HEAD/pnpm)) |
[`11.5.1` →
`11.5.2`](https://renovatebot.com/diffs/npm/pnpm/11.5.1/11.5.2) |
![age](https://developer.mend.io/api/mc/badges/age/npm/pnpm/11.5.2?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/pnpm/11.5.1/11.5.2?slim=true)
|

---

### Release Notes

<details>
<summary>pnpm/pnpm (pnpm)</summary>

###
[`v11.5.2`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1152)

[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.5.1...v11.5.2)

##### Patch Changes

- Peer dependency resolution now reuses the peer contexts already
recorded in the lockfile when those providers are still present in the
dependency graph and still satisfy the peer ranges. This avoids
unnecessary peer-context rewrites during lockfile regeneration. Current
manifest choices remain authoritative: a newly added, explicitly
updated, or aliased direct provider, a changed nested provider, or a
locked version that no longer satisfies the range still takes
precedence.

- The lockfile verifier now checks that a registry entry pinning an
explicit `tarball` URL points at the artifact the registry's own
metadata lists for that `name@version`. Previously a tampered lockfile
could pair a trusted `name@version` with an attacker-chosen tarball URL
(and a matching integrity for those bytes), so the install fetched the
attacker's bytes. A mismatch — or any entry that can't be confirmed
against the registry — is rejected with `ERR_PNPM_TARBALL_URL_MISMATCH`.
Non-registry resolutions (`file:`, git-hosted, etc.) and registry
entries without an explicit tarball URL (the URL is reconstructed from
name+version+registry, so it is inherently bound) are unaffected;
non-standard registry tarball URLs (npm Enterprise, GitHub Packages)
still pass because they match the metadata.

- Fix `pnpm update --recursive --lockfile-only <pkg>@&#8203;<version>`
crashing with `Invalid Version` when the catalog entry for `<pkg>` is a
version range (e.g. `^21.2.10`) and `catalogMode` is `strict` or
`prefer`. The catalog–version comparison now skips the equality check
when either side is a range rather than passing a range to
`semver.eq()`, so range specifiers fall through to the existing mismatch
handling instead of throwing
[#&#8203;11570](https://redirect.github.com/pnpm/pnpm/issues/11570).

- Avoided a Node.js crash when pnpm exits after network requests on
Windows.

- Fixed packages being materialized into the virtual store without their
root-level files (`package.json`, `LICENSE`, README, root entrypoints)
when multiple `pnpm install` processes ran against the same
store/workspace concurrently. The fast import path used to destructively
empty the shared target directory, so a concurrent importer could wipe
files another importer had already written; if the surviving files
included the `package.json` completion marker, every later install
treated the broken directory as complete and never repaired it. The fast
path now imports directly only when it can create the target directory
exclusively, and otherwise builds the package in a private temp
directory and atomically renames it into place
[#&#8203;12197](https://redirect.github.com/pnpm/pnpm/issues/12197).

- Fix dependency build scripts not running under the global virtual
store (`enableGlobalVirtualStore`).

In a workspace install, dependency build scripts are deferred to a
single `rebuild` pass (`buildProjects`). That pass resolved each
package's location from the classic
`node_modules/.pnpm/<depPathToFilename>` layout, which does not exist
under the global virtual store — so native dependencies (e.g. packages
using `node-gyp` / `prebuild-install`) were never built and failed to
load at runtime (`Cannot find module .../build/Release/*.node`).

`buildProjects` now resolves the global-virtual-store projection
directory (`<storeDir>/links/<hash>`, computed with the same graph hash
the installer uses) when `enableGlobalVirtualStore` is set, and
serializes concurrent builds of the same shared projection so parallel
workspace projects don't race on the same directory.

- Don't promote a `runtime:` dependency (such as the Node.js version
from `devEngines.runtime` or `pnpm runtime set`) into a catalog when
`catalogMode` is `strict` or `prefer`. A `runtime:` dependency
round-trips to `devEngines.runtime`, which only recognizes the
`runtime:` protocol; cataloging it rewrote the manifest entry to
`catalog:`, which broke that round-trip, stranded it in
`devDependencies`, and left `devEngines.runtime` untouched.

- Skip lockfile `minimumReleaseAge`/`trustPolicy` verification for
non-registry tarball protocols (for example `file:`), so local tarball
dependencies are not incorrectly checked against npm registry metadata.

</details>

---

### Configuration

📅 **Schedule**: (UTC)

- Branch creation
  - "before 7am every weekday"
- Automerge
  - At any time (no schedule defined)

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/apify/crawlee-python).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMDkuNCIsInVwZGF0ZWRJblZlciI6IjQzLjIwOS40IiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Author: renovate[bot]

website/package.json

@@ -70,5 +70,5 @@
         "rimraf": "^6.0.0",
         "typescript": "^6.0.0"
     },
-    "packageManager": "pnpm@11.5.1"
+    "packageManager": "pnpm@11.5.2"
 }