[Bug]: pnpm lockfile parsed and translated when building unrelated targets

### What happened?

When building any non-JS target, Bazel always passes by the root /BUILD.bazel file and its `npm_link_all_packages` macro call, which creates the virtual store. Hence, any changes to the `pnpm-lock.yaml` file, which happens quite often in the JS ecosystem, will trigger reparsing and translating the lockfile into Starlark files, even when the Bazel target to build does not have any relationship to JS (e.g., Golang only). This creates some friction and unnecessary waiting times.

### Version

Development (host) and target OS/architectures:

Output of `bazel --version`: `bazel 7.6.1`

Version of the Aspect rules, or other relevant rules from your
`WORKSPACE` or `MODULE.bazel` file: 3.0.1

Language(s) and/or frameworks involved:
Go, Python, TS/JS

### How to reproduce

```shell
This can be demonstrated in the rules_js repository itself. At the root run:

bazel clean --expunge
bazel build //:buildifier

There is a small time where it shows the parsing and translation of the pnpm-lock.yaml file into Starlark dependencies although not needed for the build target. This is exacerbated if the pnpm-lock.yaml file is as large as 100k lines and the system maybe not the latest anymore.
```

### Any other information?

@dzbarsky mentioned an inflight PR converting that macro to be symbolic, which might be a solution.

Reproduce the behavior with `bazel clean --expunge` and `bazel build //:buildifier` from the repository root. Read `/BUILD.bazel`, the `npm_link_all_packages` macro call, and the `pnpm-lock.yaml` handling; done means unrelated targets no longer parse and translate the lockfile unnecessarily.

Written by the indexing model from the issue text.