[FEATURE] Let `marketplace add` set request headers, so token authenticated marketplaces are reachable without hand editing JSON

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

A url source marketplace already supports a headers object, and it works. On 2.1.228 I
registered a marketplace served from an artifact registry with only an
Authorization: Bearer header and no credential in the URL, and marketplace update fetched
and validated it successfully.

The problem is that nothing in the product lets you set it. claude plugin marketplace add
takes a source and two flags, --scope and --sparse. The /plugin then Add Marketplace
prompt takes a bare URL. Neither offers a way to attach a header, so the only credential a user
can actually supply through a supported path is basic auth embedded in the URL.

That leaves two bad outcomes. Registries that issue bearer tokens and do not accept basic auth
cannot be used at all from the command. And for those that do accept basic auth, the credential
ends up inside the marketplace URL, where it is then printed in cleartext in /plugin and in
claude plugin marketplace list, which is #86136.

Today the workaround is to hand write the entry into settings.json or
known_marketplaces.json. That works, but it is not something you can put in onboarding
instructions for a team, and the headers field is almost undiscoverable. It appears once in
the marketplace documentation, in a sentence about archive downloads, and it is absent from the
field table for url sources.

Proposed Solution

Add a repeatable --header flag to claude plugin marketplace add, matching the flag
claude mcp add already has, so the two commands behave consistently:

claude plugin marketplace add https://artifacts.example.com/claude/marketplace.json \
  --header "Authorization: Bearer $REGISTRY_TOKEN"

The value would be stored as the headers object on the url source that the code already
consumes, so no new storage format or fetch path is needed.

Alongside that, offer an optional header field in the /plugin then Add Marketplace prompt, so
the interactive path is not a dead end for anyone whose marketplace needs a token.

Environment variable expansion in the value, as MCP server configuration already supports, would
let the token stay out of shell history and out of any file that gets committed.

Alternative Solutions

Basic auth in the URL. Works for registries that accept it, but the credential is then part of
the marketplace URL and gets rendered in cleartext, and plenty of artifact registries expect a
bearer token rather than basic auth.

Hand editing settings.json or known_marketplaces.json. This is what I do now. It works, but
it means telling every user to edit JSON by hand, and a typo in the registry file breaks plugin
operations.

An extraKnownMarketplaces entry pushed through managed settings. A good answer for an
organization with MDM in place. It does nothing for an individual developer adding a
marketplace to their own machine.

Git credential helpers. Not applicable. A url source is a plain HTTPS document fetch with no
git remote involved, so no helper is ever consulted.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

1. A team publishes its internal plugins to an artifact registry that authenticates with bearer

tokens.

1. Onboarding documentation wants to give new engineers a single command to run.
2. Today the only command that works puts a credential in the URL, so the documentation instead

has to ask people to open a JSON file and add an entry by hand, and to redo it when the token
rotates.

1. With --header, the instruction becomes one line that reads a token from the environment,

and the credential never appears in the URL, in the marketplace list, or on screen.

Additional Context

This is a small change in scope, because the fetch path and the storage format both exist
already. The headers object is read for url sources and is used when downloading plugin
archives from the marketplace's own origin. The gap is only that no command writes it.

Documenting the headers field in the url source table would be worth doing at the same time.
Right now someone hitting this problem has no way to discover that the capability is there,
which is how you end up assuming basic auth is the only option.

Related: #86136 covers the credential being printed in cleartext once it is in the URL. This
request is about not needing it in the URL in the first place.