`apm install` fails on second run when lockfile contains commit SHAs for subdirectory packages

[sergio-sisternes-epam]

Bug

Running apm install twice in succession fails on all subdirectory (monorepo) packages during the second run.

Steps to reproduce

1. Start with a clean project (no apm_modules/, no apm.lock)
2. Run apm install --trust-transitive-mcp — succeeds, generates apm.lock
3. Run apm install --trust-transitive-mcp again — all subdirectory packages fail with:

   fatal: Remote branch <commit-sha> not found in upstream origin
   

Root cause

When the lockfile exists, the install logic appends the locked commit SHA as a git reference (#<sha>) to the download ref string. For subdirectory packages, download_subdirectory_package passes this SHA as branch=<sha> with depth=1 to git clone. Git shallow clones (--depth=1 --branch=X) only accept branch/tag names, not arbitrary commit SHAs — so every package fails.

Expected behavior

Repeated apm install should be idempotent — the second run should produce the same result as the first.

Fix

Detect when the ref is a commit SHA in download_subdirectory_package and use a full clone + checkout instead of --depth=1 --branch=<sha>.