PnpmLock::parse inventories a pnpm 11 env-lockfile document's configDependencies as project packages, while InstalledPackages and the upstream evidence reader drop it #1949

[agent] Filed by the scheduled architecture audit (audit-core). Register: #1830 (comment).

Kind: bug. Register ID: A64.

Problem. pnpm 11+ writes the env lockfile (configDependencies / packageManagerDependencies) as a first YAML document ahead of the project lock. grammar::main_document exists to drop it (grammar.rs L91-L109),`` but only some readers call it:

• InstalledPackages drops it (mod.rs L534), and so does pnpm_lock_tarball_evidence (upstream/npm.rs L1514-L1517).````
• PnpmLock::parse scans the whole text (mod.rs L386-L394). The lock inventory reads PnpmLock::parse(text).entries() (lock_inventory/pnpm.rs L95-L97).`````

Executed (a scratch test on cbbbdb9). The lock's env document locks cfg@1.0.0 and its main document locks a@1.0.0. The readers disagree:

PnpmLock::parse(text).entries() names = ["cfg", "a"]
pnpm_packages(main_document(text))    = ["a@1.0.0"]
InstalledPackages::contains("cfg")    = false

So scan inventories, and sends to the API, a config dependency that the project's install never links. Patching paths that use InstalledPackages then disagree with the inventory about the same package.

Proposed change. PnpmLock::parse applies main_document itself. The callers that need the env document (none today, as far as grep shows) can read it explicitly. Add a unit test in formats/pnpm/mod.rs with a two-document lock that asserts entries() omits the env-document packages.

Size. 1–2 files, about 15 lines plus the test.

Acceptance criteria.

• Single-document locks behave exactly as before; the existing formats::pnpm and lock_inventory tests pass.
• The new two-document test asserts entries(), InstalledPackages and vendored_npm_uuids agree.