[FEATURE] Persist marketplace object-form deps; accept SHA catalog pins

[sergio-sisternes-epam]

Is your feature request related to a problem? Please describe.
On apm-cli 0.30.0, operating a registry-only marketplace (immutable commit-SHA pins, nested deps that must resolve through the catalog) hits several CLI mismatches:

1. apm install plugin@<catalog> validates through the marketplace, then writes owner/repo#sha git shorthands into consumer apm.yml. Durable marketplace identity requires hand-editing object form (name + marketplace) and reinstalling.
2. plugin@marketplace is the advertised install identity, but the same string is rejected inside apm.yml. Only object form persists.
3. apm marketplace check fails raw commit-SHA catalog pins even when apm pack and CI drift checks succeed.
4. The same marketplace Git URL can be registered under two names (e.g. a local alias and the published catalog name) with no warning; @marketplace suffixes and audit then disagree.
5. apm deps list Source stays github even when the lockfile has discovered_via / marketplace_plugin_name.
6. After apm install -g, parked executables require apm approve from ~/.apm because approve has no --global and follows cwd.

Describe the solution you'd like

• Persist name + marketplace (optional version) in consumer apm.yml on apm install plugin@<catalog>. Keep resolved git coordinates in the lockfile.
• Accept commit-SHA refs in apm marketplace check for registry-only catalogs, or document that pack+CI is the SHA-pin gate.
• Align CLI shorthand with manifest grammar (accept plugin@marketplace in apm.yml, or stop advertising that string as the persisted identity).
• Warn in apm doctor / apm marketplace list when one source URL is registered under multiple names.
• Surface catalog provenance in apm deps list from lockfile discovered_via.
• Let apm approve target user scope after -g installs without cd ~/.apm.

Describe alternatives you've considered

• Keep expanding marketplace installs to git shorthands and document a manual rewrite step (what operators do today; easy to regress).
• Treat apm marketplace check failures on SHA pins as expected and ignore them (confusing for CI authors).
• Continue using lockfile fields only for provenance (works, but deps list misleads agents and humans).

Additional context
apm marketplace audit is already the right consumer check for nested catalog resolution. Nested package dependencies.apm must use object form on 0.30.0; git owner/repo shorthands install but audit as bypasses. Happy to split this into separate issues if maintainers prefer.

[sergio-sisternes-epam]

Triage decision

needs-design

Proposed labels

theme/security
area/marketplace
area/lockfile
area/cli
type/feature
status/needs-design

Milestone

null

Suggested next action

Split the six concerns into focused issues, then settle the marketplace identity and SHA-pin policy contracts before implementation.

Suggested issue comment

Thanks for documenting the registry-only workflow so concretely. These are real consistency gaps, but the issue currently combines six independently shippable changes across manifest persistence, dependency grammar, marketplace validation, source identity, lockfile presentation, and approval scope.

Before implementation, please split the concerns into focused issues and resolve two contract decisions: whether `plugin@marketplace` is valid persisted `apm.yml` syntax, and whether `apm marketplace check` accepts commit-SHA pins or delegates that guarantee to pack plus CI. The existing `apm approve --user` path should also be evaluated before adding another global-scope surface.

The marketplace identity and lockfile implications make this a security-sensitive design boundary, so this remains milestone-free until those contracts are explicit.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The request maps to real package-manager tasks: preserving registry identity, accepting the same dependency syntax across CLI and manifest surfaces, displaying provenance, and operating user-scope approvals predictably. The six asks should be split so each user contract can be specified and tested independently.

Supply Chain Security Expert -- Risk-Surface Reviewer

Marketplace name resolution, immutable SHA pins, source aliases, and lockfile provenance are package identity and integrity surfaces. theme/security is the primary theme, with area/marketplace and area/lockfile; the design must prevent registry bypass and ambiguous source identity.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- the author is an established repository collaborator and the issue already provides a detailed operator workflow.

Python Architect -- Architecture Reviewer

Activated because the proposal changes manifest grammar, persistent dependency representation, marketplace validation, source identity, lockfile presentation, and CLI scope behavior. The bundle is cross-cutting and contains mutually exclusive design choices, so status/needs-design is required before implementation.

Doc Writer -- Documentation Reviewer

Activated because whichever syntax and SHA-pin policy is selected must be reflected in marketplace, manifest, and approval documentation. The label cap prioritizes the implementation surfaces over area/docs-site, but documentation remains part of the eventual acceptance criteria.

APM CEO -- Triage Arbiter

The need is valid, but the current issue is too broad for safe implementation and mixes policy choices with independent usability fixes. Ratify needs-design, no priority, and no milestone; split the work and decide the marketplace identity and SHA-pin contracts first.

{
  "kind": "apm-triage-panel",
  "schema_version": 2,
  "decision": "needs-design",
  "decision_detail": "Six distinct marketplace and portability concerns span manifest persistence, dependency grammar, marketplace checks, source identity, lockfile provenance, and approval scope. Several are unresolved design forks, and the issue explicitly offers to split.",
  "theme": "theme/security",
  "areas": ["area/marketplace", "area/lockfile", "area/cli"],
  "type": "type/feature",
  "status": "status/needs-design",
  "priority": null,
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Split the six concerns into focused issues, then settle the marketplace identity and SHA-pin policy contracts before implementation.",
  "public_comment": true,
  "triage_evidence": {
    "fingerprint_version": 1,
    "fingerprint": "sha256:b5be519529a3a97c2b9ce18a659d89b732d37de5b43d9059d8d36e4d360b2053",
    "provenance_version": 1,
    "provenance": {
      "trusted_sources": ["issue_body", "human_discussion", "reproduction_evidence", "producer_rubric_revision"],
      "source_refs": ["https://github.com/microsoft/apm/issues/2903"],
      "producer_rubric_revision": "triage-reuse@v1+0880fe2438b22e127100fa0f164859ca2c9572fe",
      "reuse_state": "fresh",
      "legacy_state": "versioned",
      "invalidators": []
    }
  },
  "comment_markdown": "Thanks for documenting the registry-only workflow so concretely. These are real consistency gaps, but the issue currently combines six independently shippable changes across manifest persistence, dependency grammar, marketplace validation, source identity, lockfile presentation, and approval scope.\n\nBefore implementation, please split the concerns into focused issues and resolve two contract decisions: whether `plugin@marketplace` is valid persisted `apm.yml` syntax, and whether `apm marketplace check` accepts commit-SHA pins or delegates that guarantee to pack plus CI. The existing `apm approve --user` path should also be evaluated before adding another global-scope surface.\n\nThe marketplace identity and lockfile implications make this a security-sensitive design boundary, so this remains milestone-free until those contracts are explicit."
}