Remote-only entries: publish to mpak without an artifact (Asana, Notion, etc. as first-class servers)

[mgoldsborough]

Today mpak only accepts entries with an uploaded .mcpb artifact via OIDC announce. Curated remote MCP services (Asana, Notion, Granola, Gmail, HubSpot, Outlook, Zoom — anything served over HTTP/SSE rather than spawned locally) live in consumer registries (e.g. NimbleBrain's StaticRegistry) instead of mpak.

The upstream ServerDetail schema explicitly supports both shapes:

• packages[] — local installs (mcpb / npm / pypi / oci)
• remotes[] — remote MCP servers reachable at a URL via streamable-http or sse

The schemas package already defines RemoteTransportSchema. The composer just doesn't emit remotes[] because no manifest declares them today.

What's missing

1. Announce path that accepts metadata-only entries. POST /v1/bundles/announce requires an artifact at the GH release. A new POST /v1/servers/announce (or extending the existing one) that accepts a manifest with no packages[] / artifacts — the OIDC token still proves repo ownership for trust.
2. Composer projects remotes[]. Pull from manifest._meta["dev.mpak/registry"].remotes[] (or wherever the author declares them) and emit upstream RemoteTransport entries. ~10 lines.
3. Per-bundle authoring convention. Document the manifest shape for a remote-only entry — likely a stub manifest.json with the standard mcpb v0.4 fields plus the remotes block under _meta. The bundle's GH repo is config-only (no source code, no .mcpb build).
4. mcpb-pack action support for remote-only repos. A new mode (announce-only: true / build: false is mostly there) that skips the artifact upload but still announces.

Why this matters

• Single source of truth for discovery. Today io.asana/mcp, com.notion/mcp, ai.granola/mcp etc. are duplicated across every consumer's curated YAML (NimbleBrain's catalog.yaml, Claude Desktop's bundled list, etc.). With remote-only mpak entries, consumers query /v1/servers once and get the union.
• Eliminates StaticRegistry as a separate concept. NimbleBrain's StaticRegistry exists only to host these — once mpak hosts them natively, it becomes a MpakRegistry query with a tag filter.
• Trust + provenance for remote services. Same OIDC chain that vouches for stdio bundles can vouch for remote endpoints — so consumers know "this is the canonical Asana MCP URL, signed by Asana's GH org".

Open questions

• Who publishes vendor-owned remote servers? Asana publishing io.asana/mcp is ideal but may take partnership. Mpak could host curator-owned shadow entries (ai.nimblebrain/asana-proxy) as a stopgap.
• Health probing. Should mpak verify the remote URL is reachable at announce time? Periodic health checks?
• OAuth flow declaration. The _meta["ai.nimblebrain/connector"] extension NimbleBrain uses today (auth type, operatorSetup, scopes) — should that move into _meta["dev.mpak/registry"].oauth so any consumer can discover the OAuth metadata, not just NimbleBrain?

Sequencing

This is a new capability, not a deprecation cleanup — separate from issues #101 / #102 / #103. Could ship in parallel.