Add Custom model endpoint provider with explicit API types

Summary

Add a Custom provider alongside Azure OpenAI, Foundry (classic), and New Foundry in the existing multi-model endpoint system. Custom endpoints must use an explicit API type instead of relying on endpoint-path or model-name inference.

User Value

Administrators and permitted workspace managers can connect SimpleChat to additional model endpoints while retaining the existing endpoint governance, model selection, secret storage, testing, and model metadata experience. All user-facing product language must call this provider Custom.

Proposed Behavior

• Add Custom to the provider list for global, personal, and group model endpoints.
• Require a Custom API type: OpenAI API, Azure OpenAI API, or Anthropic.
• Support API key authentication only for Custom endpoints in the initial release.
• Keep the endpoint FQDN/base URL field and show only protocol-relevant connection fields.
• Do not offer model discovery or Fetch Models for Custom endpoints; models are entered manually.
• Use a model name/ID for OpenAI API and Anthropic rows, and a deployment name for Azure OpenAI API rows.
• Preserve common model metadata: display name, response length, description, enabled state, and icon.
• Route inference, streaming, Semantic Kernel agents, workflows, summaries, metadata extraction, and other multi-endpoint consumers using the saved Custom API type.
• Keep Test Connection available and construct the correct request for each API type.
• Store API keys through the existing Key Vault-backed endpoint secret flow and strip secrets from all frontend payloads.
• Preserve all existing Azure OpenAI and Foundry endpoint behavior and saved endpoint documents.

Acceptance Criteria

• Admin, personal workspace, and group workspace endpoint UIs expose Custom with the three supported API types.
• Custom authentication is fixed to API key and identity/model-discovery controls are unavailable.
• Custom models are added manually with protocol-correct model/deployment fields and shared metadata fields.
• OpenAI API requests use the configured model name and OpenAI-compatible client contract.
• Azure OpenAI API requests use the configured deployment name and Azure OpenAI client contract.
• Anthropic requests use the configured model name and Anthropic Messages API contract.
• Test Connection works for each Custom API type without exposing provider error details or secrets.
• Chat, streaming, local agents, workflows, tabular/background work, summaries, and metadata extraction preserve and honor the Custom API type.
• Endpoint normalization, frontend sanitization, Key Vault secret preservation, governance checks, and backward compatibility are covered by regression tests.
• UI automation covers provider/type selection, conditional fields, manual model entry, persistence, and test-request payloads.
• Feature documentation and current-version metadata are updated.

Notes

• No model-list discovery is in scope for Custom endpoints.
• No Custom authentication method beyond API key is in scope for the initial release.
• Existing Foundry protocol inference remains for legacy endpoint records; new Custom records should use their explicit API type.
• Product copy should not characterize Custom endpoints by hosting location or ownership model.