Model Config: CRUD endpoints and completion_type as array

[vprashrex]

Is your feature request related to a problem?
Currently, model_config.completion_type is a single enum, limiting each model to one type. This requires duplicate rows for models that need to support both text and stt, complicating management and necessitating migrations for changes.

Describe the solution you'd like

• Convert completion_type to an array to allow multiple supported types in a single row.
• Add POST (single + bulk), PATCH (single + bulk), and DELETE endpoints on /api/v1/models.
• Centralize Provider, CompletionType, and Modality as StrEnums in app/models/llm/constants.py.
• Validate input_modalities / output_modalities against the Modality enum.

Why is this enhancement needed?

• Allows one row per model, eliminating the need for workarounds.
• Enables adding new models or adjusting pricing without requiring a deploy.
• Provides a single source of truth for enums, ensuring invalid modality values are rejected at the API boundary.

Original issue

Describe the current behavior
A clear description of how it currently works and what the limitations are.
model_config.completion_type is a single enum — one model can only support one type. To use gemini-2.5-flash for both text and stt, you'd need duplicate rows, but (provider, model_name) is unique. Also, model_config API is read-only — adding/editing models requires a migration + deploy.

Describe the enhancement you'd like
A clear and concise description of the improvement you want to see.

1. Convert completion_type to an array so a row can list multiple supported types.
2. Add POST (single + bulk), PATCH (single + bulk), DELETE on /api/v1/models.
3. Centralise Provider, CompletionType, Modality as StrEnums in app/models/llm/constants.py.
4. Validate input_modalities / output_modalities against the Modality enum.

Why is this enhancement needed?
Explain the benefits (e.g., performance, usability, maintainability, scalability).

• One row per model regardless of supported types — no workarounds.
• Add new models / tweak pricing without a deploy.
• Single source of truth for enums; invalid modality values rejected at the API boundary.