[BUG] OpenAPM local-path containment contradicts supported trusted-local sibling paths

[danielmeppiel]

Describe the bug
OpenAPM req-mf-016 and the established CLI/shipped-guide contract disagree about trusted local dependencies outside the consuming project root.

At source revision 69f41ab7f88ac20d43728bc6d8e1e18b6a7112e3:

• OpenAPM req-mf-016 says: "The resolver MUST refuse any local-path entry whose normalised form contains .. segments that would escape the project root, with a diagnostic naming the offending path."
• The shipped dependency guide explicitly supports local sibling layouts outside the consuming project root, anchored to the declaring local package. Remote-declared paths instead remain contained in the authenticated remote repository.
• The local materialization owner deliberately does not enforce consumer-project-root containment for trusted local packages, and explains that remote-parent expansion/rejection is the untrusted-source boundary. Locked local replay in deps/path_anchoring.py follows the same local-anchor contract.

The specification describes project scope as rooted at the consumer project, but user scope as independent of a project root. req-mf-016 does not explain a user-scope boundary or an exemption for trusted local declaring parents. Silently treating its MUST as nonnormative, or redefining the project root as an arbitrary common ancestor, would conceal the discrepancy.

To Reproduce

1. Compare the three pinned sources above.
2. Consider a consumer at /R/consumer that explicitly depends on local /R/packages/parent, whose manifest declares path: ../child.
3. The shipped guide and existing project-scope behavior admit /R/packages/child, despite it being outside the consumer root. The executed project-relative control is documented in [BUG] Global install exits successfully after silently omitting a relative local transitive dependency #2815.
4. Apply req-mf-016 literally: the escaping relative entry appears forbidden. For user scope, the requirement does not supply a replacement for the consumer project root.

Expected behavior
A reviewed specification decision should clearly distinguish source anchoring, trusted-local admission, remote-repository containment, local-copy symlink containment, and installation scope. Normative wording, shipped guidance, implementation claims, and appropriate conformance examples should agree.

Clarify the trust boundary and user-scope interpretation explicitly. Do not weaken remote-source, symlink, materialization, or deployment containment merely to resolve this prose conflict. If the specification artifact or conformance fixtures change, they should receive the normal specification review.

Environment (please complete the following information):

• OS: N/A for the normative discrepancy; the linked behavioral controls ran on macOS
• Python Version: 3.12.10 for the linked behavioral controls
• APM Version: source revision 69f41ab7f88ac20d43728bc6d8e1e18b6a7112e3
• VSCode Version (if relevant): N/A

Logs
N/A. This report concerns a verified contradiction between the published requirement, shipped guide, and documented implementation boundary; the concrete CLI reproduction and controls are in #2815.

Additional context
Discovered by the independent #2815 fix owner during APMLifecycle Phase 2 (#2813) contract review. The maintainer explicitly chose to preserve established trusted-local sibling support for the bounded user-scope fix and track this pre-existing specification conflict separately. That ruling does not reconcile the specification or authorize an unreviewed spec change.

The #2815 fix must continue to reject direct/unanchored user-relative input and preserve remote/symlink safety. This issue is the separate specification follow-up, not permission to broaden that fix or begin Phase 3 transaction work.