[BUG] stale-file cleanup reports dependency key as deletion location

Describe the bug

The stale-file cleanup diagnostic presents a dependency key as though it were the filesystem location from which files were deleted:

f"Cleaned {count} stale {noun} from {dep_key}"

For an absolute local-path dependency, the displayed path identifies the source package even though cleanup occurs under the deployment root. A before/after inventory confirms that the source remains unchanged.

To Reproduce

1. Create a local-path package containing a skill and an ignored generated file.
2. Install it globally with --target agent-skills.
3. Uninstall it by its _local/<name> key.
4. Observe output such as:

Cleaned 6 stale files from /absolute/path/to/source

The source tree remains unchanged; /absolute/path/to/source is the dependency identifier passed as dep_key, not the deletion location.

Expected behavior

The diagnostic should not describe a dependency identifier as a deletion location. It can report the package relationship directly:

Cleaned 6 stale deployed files for _local/source

If a location is reported, it should be derived from the actual deleted targets rather than dep_key.

Environment (please complete the following information):

• OS: macOS
• Python Version: 3.14.7
• APM Version: 0.31.0 installed with Homebrew
• VSCode Version (if relevant): Not applicable

Logs

The relevant output is included in the reproduction above.

Additional context

Both CommandLogger.stale_cleanup implementations format dep_key after from, and generic install-cleanup and manifest-reconciliation paths call those methods.

Start by locating both CommandLogger.stale_cleanup implementations, then trace the generic install-cleanup and manifest-reconciliation callers described in the issue. Reproduce the local-path uninstall case and update the diagnostic so it reports the deployed-file relationship or actual deletion targets without presenting dep_key as a filesystem location.