chore: Update ToolHive API models

[stackloke2e]

Summary

This PR updates the ToolHive API models generated from the latest OpenAPI specification.

Changes

• Updated Pydantic models in src/mcp_optimizer/toolhive/api_models/

Notes

• This PR was automatically generated by the update-thv-models workflow
• The models are generated using datamodel-codegen from ToolHive's OpenAPI endpoint

🤖 Generated with GitHub Actions

[claude]

PR Review - ToolHive API Models Update

This PR updates auto-generated Pydantic models from ToolHive's OpenAPI spec. Overall looks good with no major issues.

Key Changes

• New modules: authserver.py, skills.py, templates.py, upstreamswap.py (OAuth/OIDC auth server configs, skills management)
• Breaking change: MCPClient → ClientApp, MCPClientStatus → ClientAppStatus in client.py
• New client apps: Added gemini-cli, vscode-server, mistral-vibe, codex to ClientApp enum
• Removed field: virtual_mcp field removed from Workload in core.py
• Enhanced configs: New OAuth caching fields in remote.py, Kubernetes metadata in registry.py

Findings

Breaking Changes:

• Type renames (MCPClient → ClientApp) are breaking but appear safe—no usages found in codebase

Code Quality:

• Generated code follows project conventions (native types: list[str], dict[str, str])
• Pydantic models properly configured with Field descriptions
• Proper use of StrEnum for enums

Minor Issues:

• Line 61 in skills.py: TODO comment suggests future refactoring needed
• v1.py: UpdateRegistryResponse.message field removed (minor breaking change)

Recommendations

1. Verify no downstream consumers use MCPClient/MCPClientStatus types
2. Consider adding migration notes if this is a public API
3. Run full test suite to validate compatibility

Security: No concerns—proper handling of secrets via file/env references

Performance: No concerns—models use appropriate nullable fields

Verdict: Approve pending test results