chore: remove legacy registry schema and validator

[rdimitrov]

Summary

Removes the legacy ToolHive registry schema artifact and its validation entry points from toolhive-core. The Go types (Registry, ImageMetadata, RemoteServerMetadata) and the registry/converters/ package stay — they remain toolhive's internal in-memory model and are still used by toolhive's API providers and toolhive-catalog's update_metadata provenance verification.

• Deletes registry/types/data/toolhive-legacy-registry.schema.json and removes it from the //go:embed directive
• Deletes the ValidateRegistrySchema function and the (*Registry).Validate() method
• Drops the corresponding test cases (TestRegistrySchemaValidation, TestValidateRegistrySchemaWithInvalidJSON, TestMultipleValidationErrors, TestRegistry_Validate); upstream / skill / publisher-provided extensions tests are unchanged
• Removes the stale schema-file reference comment from registry_types.go
• Drops the schema from the .github/workflows/release.yml release-asset upload step

Why this is safe

The catalog-side removal already merged in stacklok/toolhive-catalog#1215 — that repo no longer builds registry-legacy.json and no longer calls ValidateRegistrySchema. After PR #1215 merged, the only remaining references to ValidateRegistrySchema and (*Registry).Validate() are in toolhive-core itself (definitions + their own tests) and in enterprise-mirror-* repos that just mirror these sources.

Critically, stacklok/toolhive's legacy-format detection in pkg/registry/upstream_parser.go does not use the schema — it uses pkg/registry/legacyhint, a pure top-level-key sniffer (looks for servers / remote_servers / groups vs. data via json.RawMessage). So removing the schema does not break legacy-format rejection in toolhive.

Cross-repo coupling (follow-up cleanups required)

After this PR ships, the following downstream consumers will lose access to the schema asset and will need coordinated cleanup:

• stacklok/toolhive consumes the schema as a release asset of toolhive-core. Referenced in its .goreleaser.yaml and .github/workflows/releaser.yml via toolhive-legacy-registry.schema.json. After this PR ships, toolhive's release will try to pull a non-existent asset. Either land a coordinated PR in stacklok/toolhive to drop that asset reference, or sequence the two PRs.
• stacklok/docs-website and stacklok/docs-website-internal mirror the schema via .github/upstream-projects.yaml (pulled from toolhive's releases) and render it at docs/toolhive/reference/registry-schema-toolhive.mdx. Once the upstream release asset disappears, the mirror will fail; the mdx page should be deleted.

Test plan

• go build ./... clean
• go test ./... — all packages pass
• task lint — 0 issues, go vet clean
• task license-check — clean
• grep -rE 'toolhive-legacy-registry\.schema|ValidateRegistrySchema|\(r \*Registry\) Validate\(\)' . returns zero results

🤖 Generated with Claude Code