feat(cloud): support Anthropic provider base URL

openspec/changes/database-llm-provider-management/design.md

@@ -10,9 +10,9 @@ administrator Console, CSRF protection, and auth audit records that this
 change can reuse.
 
 The existing runtime clients instantiate provider SDKs with no arguments and
-therefore read keys from their environment. Database-backed credentials and
-an OpenAI-compatible base URL require those clients to accept explicit values
-while preserving the unchanged direct-transport default.
+therefore read keys from their environment. Database-backed credentials and a
+custom base URL require those clients to accept explicit values while
+preserving the unchanged direct-transport default.
 
 ## Goals / Non-Goals
 
@@ -22,8 +22,8 @@ while preserving the unchanged direct-transport default.
 - Encrypt every stored Provider API key and never return or log its plaintext.
 - Switch the provider/model used by all cloud-transport Host Agents without a
   Host configuration change, Cloud API restart, or local credential.
-- Support OpenAI-compatible endpoints through a configurable base URL and
-  API key using the existing Chat Completions tool-calling implementation.
+- Support custom base URLs for Anthropic native tool use and OpenAI-compatible
+  Chat Completions tool calling without changing their respective protocols.
 - Remove Cloud API environment-based planner Provider configuration so every
   cloud-transport decision is governed by the active database profile.
 
@@ -32,8 +32,8 @@ while preserving the unchanged direct-transport default.
 - Provider usage billing, connection-test endpoints, model discovery, or
   support for protocols other than Anthropic native tool use and OpenAI Chat
   Completions tool calling.
-- Arbitrary Anthropic-compatible endpoints, custom request headers, or
-  different OpenAI-compatible parameter dialects.
+- Custom request headers or different Anthropic/OpenAI-compatible parameter
+  dialects.
 - Automatic encryption-master-key rotation. Provider API key rotation is
   supported by updating a profile; master-key rotation remains an operational
   migration until a key-ring design is separately proposed.
@@ -103,16 +103,16 @@ backup or read access would expose external-provider credentials. Alternative
 considered: a database-held master key. Rejected because it does not create a
 separate protection boundary.
 
-### D4: Treat OpenAI-compatible as a concrete wire-protocol contract
+### D4: Treat each provider wire protocol as a concrete contract
 
-Profiles have `provider_type` of `anthropic` or `openai-compatible`. An
-`openai-compatible` profile may omit `base_url` to use the official OpenAI
-endpoint, or supply an absolute HTTP(S) base URL for a compatible service.
+Profiles have `provider_type` of `anthropic` or `openai-compatible`. Either
+profile may omit `base_url` to use its official provider endpoint, or supply
+an absolute HTTP(S) base URL for a compatible proxy or provider service.
 The runtime `OpenAIToolCallingClient` gains optional `api_key` and `base_url`
 constructor arguments and constructs `OpenAI` explicitly when supplied.
-`AnthropicToolCallingClient` gains an optional explicit API key for cloud-held
-credentials; absent optional arguments retain current SDK environment
-behavior for direct transport.
+`AnthropicToolCallingClient` gains optional explicit API key and `base_url`
+arguments and constructs `Anthropic` explicitly when supplied. Absent optional
+arguments retain current SDK environment behavior for direct transport.
 
 Compatibility means the endpoint accepts OpenAI Chat Completions requests
 with the tool/function-calling fields emitted by the existing client and