[FEATURE] apm install should clean up stale deployed files when files are renamed within a package

[Boubalou]

Problem

When a file is renamed inside an APM package (e.g., a prompt file my-command.prompt.md → my-new-command.prompt.md), running apm install generates the new target files but leaves the old ones on disk as stale artifacts.

Steps to reproduce

1. Have a package with a prompt file my-command.prompt.md
2. Run apm install — files are deployed to .claude/commands/my-command.md, .opencode/commands/my-command.md, .github/prompts/my-command.prompt.md
3. Rename the source to my-new-command.prompt.md
4. Run apm install again

Expected: Old files (my-command.md, my-command.prompt.md) are removed, new files (my-new-command.md, my-new-command.prompt.md) are created.

Actual: Both old and new files exist on disk. The old files must be manually deleted.

Why this happens

The install loop writes the new deployed_files list to the lockfile, overwriting the previous one — but never computes the diff between old and new to remove orphaned files. The existing detect_orphans() in drift.py only operates at the package level (is the package still in apm.yml?), not at the file level within a package.

Suggested approach

The infrastructure is already in place — apm.lock.yaml tracks deployed_files per dependency. During apm install, for each package:

1. Read the old deployed_files from the existing lockfile
2. Integrate the package (existing logic)
3. Collect the new deployed_files
4. Compute stale = old - new
5. Delete stale files from disk

This would cover renames, deleted prompts, and any other case where a package's output file set changes between installs.

[sergio-sisternes-epam]

Thanks for the clear write-up, @Boubalou -- the repro steps and suggested approach are spot-on.

You're right that the infrastructure is already there (apm.lock.yaml tracks deployed_files per dependency). The diff between old and new deployed files during install is a clean, well-scoped enhancement.

Accepting this. Good candidate for a community contribution -- the approach you outlined (old - new = stale, delete stale) is exactly what we'd want to see in a PR.

[Boubalou]

Thanks for the comments @sergio-sisternes-epam, appreciated! I took this opportunity and went all in with the offer. The PR is up and running, waiting on your review.

I'm not gonna lie, the code itself was executed through our Agentic flow here at Mirego, but rest assure that we use the same process internally for most of our work. The spec has been reviewed prior to the implementation and the execution, followed by myself along the way, was a great learning adventure of your code base and practices.