#4170 CLI command to change an existing extension's visibility (private → public)

Problem

There is no CLI or API way to change an existing extension's visibility. The swamp docs say a private extension can only be made public in the registry UI, and that is how the registry behaves today.

That blocks automated publishing flows that build privately and release publicly. In our case, a package is pushed private while it is being built, because a deploy step needs to pull it from the registry. It should become public only after a person records a publication decision. Every step except the visibility change can run from a swamp workflow. The visibility change needs someone to click through the registry UI.

Current behaviour (CLI 20261030.132349.0-sha.3fc1170f):

• Visibility belongs to the package and is fixed by its first push.
• Pushing a later version with visibility: public (or --visibility public) reports pushed / public, but the package stays private. The docs confirm that --visibility public "does not convert an already-private extension to public". The push output gives no sign of this, so it is easy to believe the change worked.
• Pushing with visibility: private to an already-public extension returns 409.
• swamp help extension has no subcommand that changes visibility. The nearest one, promote, moves release channels.
• The only reliable check from outside the collective is an anonymous GET https://swamp-club.com/api/v1/extensions/@<collective>/<name>. It returns 404 for a private package and 200 for a public one.

Proposed solution

Add a command that changes an existing extension's visibility, backed by a registry API endpoint:

swamp extension visibility @<collective>/<name> --set public --json
swamp extension visibility @<collective>/<name> --json   # read current visibility

• It uses the same authorisation as the registry UI toggle, so collective tokens with the right scope can run it in CI.
• --json reports the visibility before and after, so a workflow can check the change without the anonymous-API workaround.
• --dry-run shows what would change.
• If permissions or entitlements prevent the change, it fails with a clear error and does not report success.
• If private → public stays UI-only by design, the command can still read visibility and should say plainly that the change must be made in the UI, with a link to the setting.

Separately, a push whose requested visibility differs from the package's applied visibility should warn, or report the applied value, rather than printing public for a package that is still private.

Alternatives considered

• Push a new version with visibility: public. This doesn't work. Visibility is set by the first push.
• Push public from the start. This doesn't work for us: the package must not be public before the decision, and a package that starts public can never go private.
• Registry UI only. This works, but it adds a manual step to an otherwise automated workflow. It also means the workflow can only check that a person made the change, using the anonymous 404/200 probe.

Related

#2198 and #2200 added private visibility at publish time. This request covers changing visibility after publication.