refactor(parsers): drive lockfile handling from one precedence list

[sonukapoor]

The problem

loadPackages handled the same five lockfiles twice, once for the repo root and once for nested discovery, as two if-chains about 100 lines apart containing 12 near-identical ScanInput literals. chooseBestLockfile in src/utils/file.ts then kept a third, separate ordering of its own.

Three copies of the same knowledge meant three chances to disagree, and they did.

The change

LOCKFILE_PRIORITY in constants.ts is now the single source of truth for precedence. src/parsers/index.ts holds a LOCKFILE_HANDLERS table keyed by filename saying how to read each one. Root detection, nested discovery and chooseBestLockfile all walk that one list.

Keying the table by filename rather than using an array means the compiler requires a handler for every entry in the priority list, so adding a sixth lockfile cannot half-land.

constants.ts was chosen as the home because utils/file.ts already imports from it, which avoids an import cycle.

Two precedence bugs this exposed

npm-shrinkwrap.json lost to package-lock.json when nested. The root chain checked shrinkwrap first, but chooseBestLockfile scored package-lock.json at 0 and never scored npm-shrinkwrap.json at all, so it fell through to the default and sorted last. The same repo resolved differently depending on whether the lockfiles sat at the root or one directory down. npm itself ignores package-lock.json when a shrinkwrap is present, so the root behaviour was the correct one. New tests cover both levels.

findNestedLockfiles picked whichever lockfile readdirSync listed first. That matched precedence only because these five names happen to sort in priority order alphabetically, and readdirSync guarantees no ordering. It now picks by precedence explicitly.

One deliberate behaviour change

A nested bun.lock now outranks a nested package-lock.json, which is what the root scan has always done. This follows from the two paths agreeing rather than being a separate decision, but it is a real change for anyone with both files in a subdirectory.

Also

buildNoPackagesMessage listed the supported lockfiles by hand in its error text. It now derives them, so the message cannot go stale.

Verification

• Full suite green: 1830 tests, 140 suites
• tsc --noEmit clean
• Two new tests, written failing first, covering nested shrinkwrap precedence in both loadPackages and chooseBestLockfile
• Real CLI runs, not just unit tests: this repo resolves to its root package-lock.json and parses 385 packages, and purpose-built fixtures confirm both nested precedence cases

src/parsers/index.ts goes from 221 lines to 176, and from 12 ScanInput literals to 3.