[3P] Curated publish + review pipeline (submission → review → versioned listing)

[serge-ivo]

Part of the open-to-third-party program. Trust model = curated review (owner decision).

• Submission flow: creator builds → submits an agent version for review (config and/or Tier-2 code).
• Catalog states: `draft → in_review → approved/listed → suspended/rejected`; every version reviewed independently; one-click rollback.
• Reviewer/moderation UI (overlaps admin [Admin][UI] Moderation controls + admin audit-log viewer #41): queue, diff view (config + code), approve/reject with reason, suspend a live agent.
• Audit trail of review decisions (reuse the admin audit log, [Admin] Foundation: access control gating + admin-action audit log #28).
• Public catalog only ever shows `listed` versions.

[serge-ivo]

Labelled deferred: no demand — not cancelled, and not started.

Per #250 ("the board contradicts the focus bet — make deferred-by-strategy legible"), and #58's own wording, which gates this work on demand rather than on readiness.

The measurement that decides it, taken 2026-08-06 over 30 days (GET /v1/admin/usage/external):

external users:  0
operator calls:  2,782
spend:           $40.92 — entirely the operator's own

This issue serves third-party creators. There are none, and nothing on the board measures progress toward getting one. Leaving it as live work makes the roadmap read as if it were in flight, which is precisely what #250 objects to.

The un-gate condition is #68's: external users on a first-party runtime agent. When that number is non-zero, this comes back — the endpoint above makes it checkable rather than a matter of opinion.

Nothing here is judged wrong or wasted. The platform work that already landed (capability registry, connector framework, declarative pipelines, per-tool consent) is what makes first-party agents cheap to build, and it stays. What is deferred is the marketplace layer on top: sandboxing untrusted creator code, curated publish review, payout metering, creator onboarding.