build: update pnpm

[ItsHarper]

Context

Step 1 for #928. See CI results at ItsHarper#4.

Description

This PR updates pnpm to the latest version (10.14.0). That version will automatically be used as long as your global pnpm is at least version 10, so as this PR documents in CONTRIBUTING.md, make sure to update that.

Since you have no particular reason to trust me, I would highly recommend verifying my pnpm-lock.yaml changes like so:

• Do an interactive rebase on all of my commits, setting each of them to edit so that it pauses after each one
• At each commit, run the following
  • git checkout HEAD~1 -- pnpm-lock.yaml
    • This will restore the previous version of the lockfile
  • pnpm install
  • git add pnpm-lock.yaml
  • After every step, you'll find that the lockfile is unchanged from what I had committed, proving that the lockfile changes were purely made by pnpm, with no hand-editing.
  • git rebase --continue

[ItsHarper]

pnpm 9.0.0 discontinued support for node 16

[ItsHarper]

I deleted this file rather than updating it because the node.js version is inherently the one thing we simply cannot guarantee will match at runtime. If a developer updates to a more recent version of node and discovers that something broke, that's useful, and we shouldn't be trying to prevent that.

[ItsHarper]

The title originally mentioned corepack, but I just learned that modern versions of pnpm (regardless of installation type) will automatically run the version of pnpm specified in the packageManager field of package.json, so corepack really isn't necessary.

[ItsHarper]

Now that all of my commits are verified, I should be done force-pushing. I'll explicitly mention if that changes.

[ItsHarper]

This option reverts to the value that used to be the default in pnpm 7. We don't technically need it, but in my view the new default is a downgrade.

[ItsHarper]

I believe the default behavior in pnpm 7 might have merely been true, but regardless, deep is very desirable since packages in this repo have dependencies on their siblings that go more than one layer deep.

[ItsHarper]

I've gone through and improved the descriptions of all open PRs (I assume you haven't read any of them yet, but I thought I'd mention it just in case).

[eventualbuddha]

Thank you for taking on these maintenance tasks! This looks good to me, but I have one quick question.

[eventualbuddha]

Can we not use the v4.1.0 tag?

[ItsHarper]

We could, but a tag can be later updated, so if a malicious person gained write access to the pnpm actions repo, they could run malicious code in this workflow without us having to do anything.

Specifying a commit provides the same protection for actions that checking in a lockfile with hashes does for npm dependencies.

I'm less worried about the official GitHub ones. In all likelihood, it would be very difficult for a rogue GitHub employee to deploy malicious code, and if they did, ~everyone would be impacted.