Is content_hash intended to be install-scope-specific? (scope-dependent relative-link anchoring)

[cffnpwr (cffnpwr)]

For skills containing relative links, the deployed_file_hashes and content_hash change with the install scope (project vs --global), even for the same resolved_commit. This makes the lockfile non-portable across scopes, so I'd like to confirm whether that is the intended premise.

Environment

• apm 0.25.0 (commit d73e6ac)
• macOS 26.5.2 (build 25F84)

Actual

When a skill contains an intra-package relative link (e.g. SKILL.md → ../../commands/foo.md), apm rewrites that link to be anchored at the deployment location during install (src/apm_cli/deps/path_anchoring.py). The result differs by scope:

• project scope: ../../../apm_modules/<repo>/commands/foo.md
• --global: ../../../.apm/apm_modules/<repo>/commands/foo.md

The difference is just the single .apm/ segment, but because the SKILL.md content changes, the deployed_file_hashes / content_hash change even for the same commit.

Observed (same skill, same commit):

• generated with project scope: content_hash: sha256:e36a77ef…
• generated with --global: content_hash: sha256:04da55da…

As a result, a lockfile generated under one scope, when used for an install under a different scope, always has a content mismatch for skills containing relative links.

How this differs from existing issues

The "apm install rewrites the lockfile on every run" lineage (#450 / #1532 / #1702 / #2078, all closed) were idempotency false positives — the lock was rewritten in the same scope even though content was unchanged. This case is different: the content genuinely differs by scope, so those fixes do not address it.

#2187 (open) is also a content_hash portability problem, but its cause is OS line-ending differences (CRLF/LF); this case is same-OS, scope-driven — a different axis. In the same spirit as #1959 (which normalized line endings out of the hash), the question is whether deploy-scope-dependent relative links should likewise be excluded from the hash.

Minimal reproduction

1. Prepare a skill package containing a SKILL.md and a commands/foo.md that the SKILL.md references via a relative path.
2. Run apm install (project scope) in some project directory; record the skill's content_hash.
3. With the same apm.yml / apm.lock.yaml, run apm install --global; observe that content_hash changes.
4. Confirm that the link inside the deployed SKILL.md differs between apm_modules/… and .apm/apm_modules/….

Questions

1. Is content_hash (which includes the deploy-scope-dependent rewritten relative links) intended to be install-scope-specific?
2. Or should the lockfile be portable across scopes, i.e. should content_hash be scope-independent?