Resolve a yarn classic file:/url copy's identity through formats::yarn::copy only: source.rs keeps a drifted second reader that hosted uses #1951

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

Kind: refactor (drifted duplicate). Register ID: A66.

Problem. Two modules answer "which package does this yarn classic file: or tarball-URL copy hold":

• Hosted (the redirect around L4593, and hosted/engine.rs L705-L714) uses classic_copy_real_name / classic_file_directory in formats/yarn/source.rs L83-L129.``
• Vendored and VEX use classic_copy_ref + CopyRef::identity in formats/yarn/copy.rs L63-L78 and L145-L166.

Executed (a scratch test on cbbbdb9), with the pattern lp2@file:../ext/lpdir:

source::classic_file_directory -> None
copy::classic_copy_ref         -> Some(Directory("../ext/lpdir"))

So hosted and vendored disagree about whether an out-of-root file: copy is a candidate. The dir/package.json join is also written three times. source.rs also normalizes through utils::cargo_workspace::normalize_rel, a Cargo helper, instead of utils::relpath.

Proposed change.

1. Keep copy.rs as the one reader.
2. Express hosted's lookup as a read_text closure over CopyRef::read_path, so out-of-root paths fail at read time rather than being dropped at parse time.
3. Delete classic_copy_real_name / classic_file_directory.

Size. 3–4 files, about −60/+20 lines.

Acceptance criteria.

• Hosted and vendored yarn classic tests pass.
• A new test asserts that hosted and vendored make the same decision for file:../ext/x, file:/abs, and a codeload tarball URL.