docs: fix link to pnpm public-hoist-pattern docs (#2800)

It looks like pnpm rearranged their docs site at some point.

### Changes are visible to end-users: yes

- Searched for relevant documentation and updated as needed: yes
- Breaking change (forces users to change their own code or config): no
- Suggested release notes appear below: yes

### Test plan

- Covered by existing test cases

Author: tyler-breisacher-zipline

docs/troubleshooting.md

@@ -96,7 +96,7 @@ https://github.com/aspect-build/rules_js/blob/a8c192eed0e553acb7000beee00c60d60a
 Sometimes the package intentionally doesn't list dependencies, because it discovers them at runtime.
 This is used for tools that locate their "plugins"; `eslint` and `prettier` are common typical examples.
 
-The solution is based on pnpm's [public-hoist-pattern](https://pnpm.io/npmrc#public-hoist-pattern).
+The solution is based on pnpm's [public-hoist-pattern](https://pnpm.io/settings#publichoistpattern).
 Use the [`public_hoist_packages` attribute of `npm_translate_lock`](https://registry.bazel.build/docs/aspect_rules_js#npm-extensions-bzl).
 The documentation says the value provided to each element in the map is:
 

npm/private/npm_translate_lock.bzl

@@ -237,7 +237,7 @@ For more about how to use npm_translate_lock, read [pnpm and rules_js](/docs/pnp
             A map of package names or package names with their version (e.g., "my-package" or "my-package@v1.2.3")
             to a list of Bazel packages in which to hoist the package to the top-level of the node_modules tree when linking.
 
-            This is similar to setting https://pnpm.io/npmrc#public-hoist-pattern in an .npmrc file outside of Bazel, however,
+            This is similar to setting https://pnpm.io/settings#publichoistpattern in an .npmrc file outside of Bazel, however,
             wild-cards are not yet supported and npm_translate_lock will fail if there are multiple versions of a package that
             are to be hoisted.