#669 Private / org-scoped collectives with member ACLs

Problem

Today a collective is effectively a publisher namespace: extension push validates only that the @collective/name prefix matches the authenticated username, and everything pushed to the registry is publicly searchable (extension search returns it to anyone). There is no way to publish an extension that is visible and installable only to a defined set of users.

This blocks a real use case: an organization wants to share a suite of extensions (models, workflows, reports) internally — a "software factory" composed of several extensions that teammates pull and compose — but the extensions encode org-specific logic (internal service glue, account identifiers, environment specifics) that must NOT be world-readable on the public registry.

The current workaround is to keep org-specific extensions as local, never-pushed models and distribute the orchestration layer entirely outside swamp (e.g. a private git repo / language package), which defeats the point of the registry for the shareable-but-private middle ground. The access boundary ends up living in GitHub, not in swamp.

Proposed solution

A notion of a collective as an access-controlled group rather than just a username-matched namespace prefix:

• A collective can have members (beyond the single authenticated owner).
• An extension can be published with a visibility setting (e.g. public | collective | private) — a --visibility flag on extension push, or a manifest field.
• collective-visibility extensions are discoverable via extension search and installable via extension pull only for authenticated members of that collective; they are omitted from results for everyone else.
• Membership management surface (invite/remove members, list collectives you belong to). auth whoami already reports "Collectives:" — extend that model so a user can belong to collectives they don't solely own.

Alternatives considered

• Public-only + scrub everything: generalize every extension so nothing org-specific is exposed, publish public. Loses the org-specific value entirely and is fragile (easy to leak an identifier).
• Keep org extensions local, never push: works but forfeits registry distribution — no pull/versioning/update story for teammates; you reinvent distribution out-of-band.
• Access control in the consuming git repo only: what's possible today; the boundary is in GitHub permissions, not swamp, so the registry can't participate in private sharing at all.

Notes

Reserved collectives (@swamp, @si) and the username-match rule would still apply; this adds a membership/visibility layer on top rather than replacing namespace validation. Verified against CLI 20260616.195738.0 — no --visibility/private flag exists on extension push and extension search has no access filter.