[Plugin Arch] Phase 5 — Refactor Model Catalog as a Plugin

[Al-Pragliola]

Summary

Refactor the existing Model Catalog implementation to fully conform to the Plugin Interface defined in Phase 2. This validates the entire plugin architecture against real, production functionality.

Motivation

The model catalog is the original and most mature catalog implementation. Refactoring it into a proper plugin proves that the new architecture can support legacy functionality, ensures the core application is truly decoupled and generic, and serves as the reference implementation for all future plugins.

Scope

• Implement the Plugin interface for the model catalog
• Register the model catalog via init() in the plugin registry
• Migrate model-specific logic out of the core server and into the plugin
• Move model-specific OpenAPI specs into the plugin's split-file structure (Phase 4)
• Ensure all existing model catalog tests pass
• Ensure backward compatibility — existing API consumers should see no breaking changes

Acceptance Criteria

• Model catalog implements the full Plugin interface
• Model catalog self-registers via init() — no hardcoded references in the server
• All existing model catalog unit and integration tests pass
• API responses are identical to pre-refactor (no breaking changes)
• Model catalog OpenAPI spec lives within the plugin directory structure
• make build && make test && make lint pass
• E2E tests pass (cd catalog/clients/python && make test-e2e)

Dependencies

• Phase 3 [Plugin Arch] Phase 3 — Unified Catalog Server #2529
• Phase 4 [Plugin Arch] Phase 4 — OpenAPI Management for Plugins #2530

References

• Parent: [Proposal] Plugin-Based Catalog Architecture and catalog-gen tool to generate new catalog types #2220