fix: Remove corepack upgrade step from corepack build target

[chris-olszewski]

The corepack step as it exists causes issues if a machine already has corepack enabled and is using the npm shim:

olszewski@chriss-mbp cli % make corepack
npm install -g corepack@latest
Usage Error: This project is configured to use pnpm

$ npm ...
make: *** [corepack] Error 1

I think we could get around this by changing to a working directory without a packageManager, but that feels very icky. Since we were only upgrading corepack in order to avoid #110 which only happens the first time a user sets up a package manager on a machine, I think this an acceptable regression in order to unblock development.

We should follow what comes out of #157 to see if we can add this back eventually.

[vercel]

@chris-olszewski is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[mehulkar]

• I think Usage Error: This project is configured to use <pkgmgr> nodejs/corepack#157 is relevant here?

• I'm not too familiar with makefile syntax, but could we change it to a conditional instead? Something like:

  which corepack
  if [ $? -ne "0" ]; then
    npm install -g corepack@latest
  fi

[chris-olszewski]

I think nodejs/corepack#157 is relevant here?

Yup, I linked to it at the end of the commit message.

I'm not too familiar with makefile syntax, but could we change it to a conditional instead? Something like:
  ```shell
  which corepack
  if [ $? -ne "0" ]; then
    npm install -g corepack@latest
  fi
  ```

We could add that, but I don't think the conditional will run for the most part since corepack is being distributed alongside node.

[mehulkar]

This makes sense to me (even before your change). It seems we should consider corepack an experiment for local dev right now and make it recommended once we've ironed out these issues?

@nathanhammond's ✅ would be useful also since he did the original work!