[FEATURE] /plugin marketplace list should display the configured git ref

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Marketplace sources in strictKnownMarketplaces / extraKnownMarketplaces already support a ref field to pin to a specific branch, tag, or commit:

{
  "extraKnownMarketplaces": {
    "my-team-tools": {
      "source": {
        "source": "github",
        "repo": "your-org/claude-plugins",
        "ref": "v1.0.0"
      }
    }
  }
}

However, there is no way to see which ref is currently active from inside Claude Code. /plugin marketplace list lists configured marketplaces and status, but does not surface the ref (or resolved SHA). The only way to inspect this today is:

jq '.extraKnownMarketplaces' ~/.claude/settings.json
jq '.extraKnownMarketplaces' .claude/settings.json

This is awkward when:

• A team standardizes on a tag like v1.2.0 and members want to confirm they're on it
• Debugging "why does my colleague have a plugin I don't" or vice versa
• Auditing what's pinned vs. what's tracking a moving branch
• The same marketplace is configured at user + project scope and you want to see which one won

Proposed Solution

Display the configured ref (and, ideally, the resolved commit SHA) in /plugin marketplace list output. For example:

my-team-tools     github:your-org/claude-plugins@v1.0.0 (a1b2c3d)   [user scope]
community-tools   github:foo/bar@main (e4f5g6h)                      [project scope]
local-dev         file:/Users/me/dev/my-marketplace                  [user scope]

Where:

• @v1.0.0 is the configured ref
• (a1b2c3d) is the currently checked-out SHA in the marketplace clone
• Scope indicator clarifies which settings file the entry came from

A JSON-output flag (/plugin marketplace list --json or similar) would also help for scripting.

Alternative Solutions

| Alternative | Limitation |
|---|---|
| Manual jq on settings files | Doesn't show resolved SHA; doesn't show which scope wins; user must know paths |
| git rev-parse HEAD inside the marketplace clone directory | Requires knowing the cache path; doesn't show the configured ref string |
| Status-only output of /plugin marketplace list | Confirms it's added, but hides the version the user is actually running |

Priority

Medium — not a blocker, but a daily papercut for anyone running a pinned internal marketplace.

Feature Category

Plugins / CLI UX

Use Case Example

Our team distributes Claude Code plugins via an internal marketplace pinned to release tags (v1.0.0, v1.1.0, ...). When someone reports "this command isn't working for me," the first question is which version of the marketplace are you on? Today the answer requires opening a JSON file. Surfacing the ref in /plugin marketplace list would make this a one-command check.

Additional Context

• Related: #15439 (adds ref/path to plugin-level sources inside marketplace.json — different scope, but same theme of version transparency)
• Related: #42424 (/plugin list should show plugin versions — sibling request at the plugin level)
• Related: #58131 (per-plugin lastUpdated in marketplace.json)

The underlying data is already known to Claude Code — the marketplace is cloned to a local cache and the ref is in settings. This is purely a display/UX gap.