Github Pages deployment docs should clarify pnpm version is encouraged

[InertSloth]

https://docs.astro.build/en/guides/deploy/github/

Per the discussion I had at withastro/action#80 with @delucis

The current documentation has you create this configuration portion in deploy.yml

# package-manager: pnpm@latest # The Node package manager that should be used to install dependencies and build your site. Automatically detected based on your lockfile. (optional)

and a bit down the page this caution:

Caution
The official Astro [action](https://github.com/withastro/action) scans for a lockfile to detect your preferred package manager (npm, yarn, pnpm, or bun). You should commit your package manager’s automatically generated package-lock.json, yarn.lock, pnpm-lock.yaml, or bun.lockb file to your repository.

Even after the PR delucis made to allow the package-manager key to truly be optional, there is still a few issues here.

1. The configuration example provided implies through convention that you can uncomment the line to have package-manager: pnpm@latest as a valid configuration, however as of the recent PR from delucis, this is not recommended per the warning Use latest PNPM version if not specified action#81

::warning title=Could not detect PNPM version::No \`packageManager\` field found in \`package.json\`. Using latest PNPM version instead. We recommend specifying \`pnpm@VERSION\` explicitly using the \`packageManager\` field in your \`package.json\`."

2. Any documentation we add that mentions using packageManager within package.json opens a can of worms due to the field being associated with Corepack, which is still experimental, experimental and not always shipped. Both Yarn and Pnpm recommend installation via Corepack, but see their documentation for an amount of "troubleshooting" information for Corepack that would not likely fit in the astro action docs.
   https://pnpm.io/installation#using-corepack
   https://yarnpkg.com/corepack

3. The configuration line and the caution do not mention needing to specify a version at all. As of delucis PR, this now works, with it defaulting to latest, but again, it will issue a warning pointing users to using corepack configuration instead. I feel the documentation could do a better job of highlighting that the version number is expected, not just latest.

I'm not exactly sure how all the above should be navigated, but having recently gone through implementing this, I do feel the documentation here could do a much better job. Given there was several duplicate issues file concerning this specific configuration line, I seem not to be alone on this, and that's just those that bothered to file an issue about it.

How do people think we should proceed?