chore: stop reading the collection registry link on external MCPs

Merged
AD
2mo ago
+249-430

AGE-3365

Stacked on #5938 — review that first; this PR's base retargets to main once it merges.

Summary

Stops the server reading or writing external_mcp_attachments.organization_mcp_collection_registry_id, the link that pointed an external MCP attachment at a collection-backed registry.

  • Drops organization_mcp_collection_registry_id from DeploymentExternalMCP, AddExternalMCPForm, ExternalMCPServer and ExternalMCPServerEntry, so it no longer appears on deployment or catalog responses and is no longer accepted when adding an external MCP server.
  • Drops it from the queries that select, upsert and clone attachments, so a cloned deployment no longer carries it forward.
  • Replaces the deployments "exactly one of registry_id / collection registry id" validation with a plain registry_id requirement.
  • Removes the tool extractor's internal-server branch, which built ServerDetails straight from selected_remotes for collection-published servers.

Attachments published from a collection stored a null registry_id. Those rows outlive the feature, so two paths change to suit: mv.DescribeDeployment no longer treats a missing registry id as an invariant violation (such a row describes an existing deployment, not a bug), and the extractor rejects one with a plain "no registry" error rather than looking up the nil UUID. In practice that means such an attachment still renders but can no longer be redeployed.

The column itself stays; the migration that drops it is the next PR in the stack.

Motivation

The collections feature is gone as of #5938, so nothing can create an attachment that points at a collection registry, and the field is dead weight on four public API types. Retiring the reads before dropping the column keeps the rollout ordered: by the time the migration lands, no deployed server selects the column.

Summary by cubic

Stops the server reading or writing organization_mcp_collection_registry_id, the link that pointed an external MCP attachment at a collection-backed registry, since the collections feature is gone. The field no longer appears on deployment or catalog responses and is no longer accepted or cloned when adding an external MCP server.

  • Drops the field from the API types, SQL queries, and the tool extractor's internal-server branch.
  • Replaces the "exactly one of registry_id / collection registry id" validation with a plain registry_id requirement and removes the now-unused validation helpers.
  • Legacy attachments from collections keep a null registry_id and still describe, but can no longer be redeployed.
  • The column stays in the database; a follow-up migration drops it.