compile: zero-config auto-compile makes root-first resolution shadow nested package versions vs Node — resolution-order decision needed (#7137/#7195 follow-up)

[proggeramlug]

Deferred decision from PR #7195's post-merge verification of #7137 (zero-config auto-compile):

For any package in compile_packages, resolve_import searches the project root before the importer's own ancestors — a deliberate inversion (top-level ESM beating nested CJS) that was narrow while the set held only hand-listed names. #7137's auto-compile puts the entire reachable dependency graph in that set, so the inversion now applies to every bare specifier in every project.

Measured divergence vs Node 26.5.1 (dup-pkg@1.0.0 top-level + dup-pkg@2.0.0 nested under a dependency):

	top:	child:
node	A-top-level-v1	B-nested-v2
perry	A-top-level-v1	A-top-level-v1 — silent version shadowing

#7195 (merged) added a report when this fires (zero false positives across eight other fixtures) — but the underlying decision is open:

1. Match Node (ancestor-first for auto-compiled packages, keep root-first only for explicitly-listed ones)?
2. Keep root-first and rely on the report (simpler mental model, but silently un-Node for nested version conflicts — common in large trees)?
3. Something version-aware?

Real npm trees hit nested duplicates constantly, and a wrong-version import is the silent-wrong-answer class. The report makes it visible; this issue is for deciding the semantics. Context: the root-first rationale is documented at the resolve_import site; #7137's compile_package_dirs dedup interacts (first-resolved wins and is cached).