[BUG] Lockfile deployed_files records inactive-target paths from package-declared targets; audit deployed-files-present unfixable on fresh checkouts

[Cianai]

Describe the bug

When a dependency package declares targets: in its own apm.yml that include harnesses the consumer has NOT activated, the consumer's apm.lock.yaml records deployed_files entries for those inactive targets — but apm install/apm update (correctly) never writes them. apm audit --ci then fails deployed-files-present on any fresh checkout, permanently.

Example: microsoft/azure-skills, microsoft/skills-for-copilot-studio, and microsoft/skills-for-fabric declare windsurf among their package targets. A consumer with:

targets:
- claude
- codex
- copilot
- cursor
- gemini

gets 67 .windsurf/skills/... entries in the lock's deployed_files (24 + 33 + 10) that never exist on disk:

│ deployed-files-present │ 67 deployed file(s) missing -- run 'apm install' to restore │

Running apm install does not restore them (windsurf is not an active target, so nothing writes them) — the message loops.

To Reproduce

1. Consumer apm.yml with the 5 targets above and dependencies.apm: [microsoft/azure-skills].
2. apm update --yes microsoft/azure-skills (or apm install on first resolve).
3. Inspect the lock: .windsurf/... paths appear under the dep's deployed_files; no .windsurf/ directory exists.
4. apm audit --ci --no-fail-fast → deployed-files-present fails with those paths.

Also tried: consumer-side per-dep restriction

- git: https://github.com/microsoft/azure-skills.git
  targets: [claude, codex, copilot, cursor, gemini]

— fresh re-resolution still records the .windsurf/ entries.

A likely-related symptom: the drift check's cache replay produces different bytes than the install write path for ~100 of the same packages' files (fabric/copilot-studio SKILL.mds), so drift also fails on a state that install itself just wrote. Both smell like the same root: lock/replay bookkeeping uses package-declared targets where install uses the active intersection.

Expected behavior

deployed_files in the lock should record the files actually deployed for the active install-target intersection (the same set install writes), so apm audit is self-consistent with apm install output on a fresh clone.

Environment

• OS: macOS (darwin-arm64)
• APM Version: reproduced on 0.22.0 and 0.24.0 (release binary, checksum-verified)

Logs

[>] Replaying install (cache-only)...
[!] azure-skills: filename-based target routing is deprecated.
[+] Replayed 21 package(s)
[>] Diffing scratch vs working tree...
[!] Drift detected: 110 file(s)
...
│          │ deployed-files-present   │ 67 deployed file(s) missing -- run     │
│          │                          │ 'apm install' to restore               │
[x] 2 of 9 check(s) failed

Additional context

The consumer repo gitignores .windsurf/ (windsurf unused), so the ghost entries make every fresh checkout / CI run audit-red while the original working copy passes only when stale ignored files happen to exist. Happy to test a fix or provide the full lock excerpt.

[Cianai]

Possibly related for triage: #2031 (per-package targets: for hook routing) touches the same targets-handling subsystem — this issue is the lockfile-bookkeeping face of it (deployed_files recorded from package-declared targets rather than the active install intersection).