Is your feature request related to a problem? Please describe.

When developing APM packages locally (e.g., iterating on a skill or instruction set in a monorepo), there is no way to install a package from a local filesystem path. The only option is to push to a remote Git repository first and then run apm install owner/repo. This creates a slow feedback loop:

1. Edit local package
2. Commit & push to remote
3. apm install owner/repo --update
4. Test changes
5. Repeat

This friction is especially painful during:

• Package authoring — developing new APM packages before publishing.
• Monorepo workflows — referencing sibling packages in the same workspace.
• Offline/air-gapped development — environments without GitHub access.

Describe the solution you'd like

Support local folder paths as APM dependencies, similar to how npm install ../my-local-package or pip install -e ./local-pkg work.

Proposed syntax options:

# CLI argument: install from a local path
apm install ./path/to/local-package
apm install /absolute/path/to/local-package

# apm.yml: declare local dependency. Temporary solution while developing locally. Published packages should not use it
dependencies:
  apm:
    - ./packages/my-shared-skills        # relative path
    - /home/user/repos/my-package        # absolute path

Key behaviours to define:

• Symlink vs. copy: Should the install create a symlink in apm_modules/ (like npm link) or copy files? Symlinks enable live iteration; copies are more predictable.
• Validation: Local packages should still be validated (require apm.yml or SKILL.md).
• Compilation: apm compile should work identically regardless of whether a dependency is local or remote.
• Lockfile: How should local deps be represented in the lockfile? Path-based entries vs. skipping lock for local.
• Transitive deps: Local packages may themselves declare remote (or local) dependencies — resolution should still work recursively.

Describe alternatives you've considered

1. Manual symlinks: Users can manually ln -s ../local-pkg apm_modules/owner/local-pkg, but this is fragile, undocumented, and bypasses validation/lockfile.
2. Git local protocol: Using file:///path/to/repo.git as a Git remote — possible but requires the local folder to be a Git repository and doesn't support non-Git folders.
3. apm link command (npm-style): A separate subcommand (apm link ../local-package) that creates a symlink entry. This could complement apm install rather than replacing it.

Additional context

• npm's file: protocol and npm link are well-understood precedents.
• This would unblock local-first package development workflows and make the inner-loop significantly faster for package authors.
• The DependencyReference.parse() method currently rejects anything that doesn't look like a remote owner/repo reference — it would need to be extended to detect and handle local paths.