Fix nil dereference crash in loadModuleFromSpecificNodeModulesDirectory

[Copilot]

Fatal crash when packageInfo.Contents is nil at the typesVersions lookup in loadModuleFromSpecificNodeModulesDirectory. This can occur under concurrent resolution when packageJsonInfoCache.Set() (backed by sync.Map.LoadOrStore) returns a stale entry with nil Contents to a thread that parsed a valid package.json.

• Add packageInfo.Exists() guard before accessing Contents.GetVersionPaths(), matching the defensive pattern at every other Contents access site in the same function

// Before
if rest != "" {
    versionPaths := packageInfo.Contents.GetVersionPaths(r.getTraceFunc())

// After
if rest != "" && packageInfo.Exists() {
    versionPaths := packageInfo.Contents.GetVersionPaths(r.getTraceFunc())

• Add compiler test case exercising subpath node_modules resolution (pkg/sub with nested package.json)

[DanielRosenwasser]

The test seems insufficient if this is about race conditions. @copilot is there a better test here? Possibly a server test or a programmatic test of our APIs?

[Copilot]

The test seems insufficient if this is about race conditions. @copilot is there a better test here? Possibly a server test or a programmatic test of our APIs?

Replaced the compiler test with a programmatic race condition test in resolver_test.go (TestResolveSubpathNilContentsRace). It uses a flipFileExistsFS wrapper to deterministically reproduce the LoadOrStore cache race:

1. Two goroutines resolve pkg/sub concurrently — both miss the package.json info-cache
2. The first caller's FileExists returns false → stores a nil-Contents cache entry
3. The second caller's FileExists returns true, but ReadFile is gated until the first's Set completes → its Set (LoadOrStore) returns the stale nil-Contents entry
4. Without the Exists() guard → nil dereference panic; with the guard → safely skipped

I verified it deterministically fails when the fix is reverted. See commit 3dc7a86.