Remove PackageCache's per-module closest package memo

[robhogan]

Context

PackageCache memoises the closest package.json for every module path, with a reverse index and a no-package set to invalidate it, and DependencyGraph calls invalidate for every changed file:

metro/packages/metro/src/node-haste/PackageCache.js

Lines 120 to 158 in 6dbe979

	invalidate(filePath: string) {
	this.#packageCache.delete(filePath);
	// Clean up any cached result for this module path (including null).
	// Derive the package.json path from the cached result to clean up the
	// reverse index.
	const cachedResult = this.#resultByModulePath.get(filePath);
	this.#resultByModulePath.delete(filePath);
	this.#modulePathsWithNoPackage.delete(filePath);
	if (cachedResult != null) {
	const packagePath = cachedResult.rootPath + sep + 'package.json';
	const modules = this.#modulePathsByPackagePath.get(packagePath);
	if (modules != null) {
	modules.delete(filePath);
	if (modules.size === 0) {
	this.#modulePathsByPackagePath.delete(packagePath);
	}
	}
	}
	// If filePath is a package.json, invalidate all module lookups pointing to it
	const modulePaths = this.#modulePathsByPackagePath.get(filePath);
	if (modulePaths != null) {
	for (const modulePath of modulePaths) {
	this.#resultByModulePath.delete(modulePath);
	}
	this.#modulePathsByPackagePath.delete(filePath);
	}
	// If a package.json was created, modified, or deleted, invalidate all
	// null-cached module results, since modules that previously had no
	// enclosing package.json may now resolve to this one.
	if (filePath.endsWith(sep + 'package.json')) {
	for (const modulePath of this.#modulePathsWithNoPackage) {
	this.#resultByModulePath.delete(modulePath);
	}
	this.#modulePathsWithNoPackage.clear();
	}

This change

After #1945 and #1946 that memo no longer pays for itself. There are 3.7x fewer lookups and each is ~2x faster. This removes it and looks up the closest package on every call. Parsed package.json contents are still cached per path.

The other reason is incremental resolution (#1944). Any cache between the resolver and the file system has to store the observations behind each entry and replay them on a hit, which is a lot of machinery for a cache worth ~3% of first-build resolution time.

It also fixes two stale-resolution bugs on main that currently need a restart: adding a nearer package.json (eg a nested package in a monorepo), and retargeting a directory symlink into another package. Both reset the graph, so everything is re-resolved against the stale memo, which is probably why nobody noticed.

The cost is ~3% of first-build resolution time (+3ms, under 0.1% of a ~4s build), ~9% when a package.json or symlink change resets the whole graph, and nothing on an ordinary edit. Retained heap after resolving drops 37% (3.0MB -> 1.9MB). Without the two PRs above, removing the memo costs 14% on a first pass.

Benchmark

AI-driven. Every resolveDependency call of one iOS dev build replayed through DependencyGraph's whole-resolution cache, so each row is something that happens in a session. 7 interleaved rounds, medians of 15 iterations.

scenario	#1946	this PR
first build (ms)	92.9	95.6 (+2.9%)
rebuild, nothing changed (ms)	7.58	7.61
after a source edit, re-resolving the edited module's 8 dependencies (µs)	155	155
after a package.json change, re-resolving everything (ms)	73.6	80.4 (+9.3%)
heap retained after resolving (MB)	3.0	1.9 (-37%)

Changelog

 - **[Fix]**: Resolver: Fix stale resolutions after adding a nearer `package.json` or retargeting a symlinked directory, which previously needed a restart

Test plan

Reproduced both bugs with a real DependencyGraph and watcher on main, using a browser redirect to show which package.json was consulted, and confirmed they're fixed here.

Benchmark app: the synthetic RN 0.87 app described in #1945 (2.8k-module bundle, 34k-file file map). Source and package.json edits are made on disk and picked up by the watcher.