Summary

Move chat model management and runtime availability to organization-scoped API routes. The API now identifies the organization in every model-management operation, applies chat model RBAC and ACLs within that organization, and returns only models the caller can use there.

Depends on #27958.

Problem

Chat model configurations now belong to organizations, but the existing experimental management and discovery APIs are deployment-shaped. Their routes do not identify an organization, SDK methods do not accept an organization ID, and item operations address a model configuration by ID alone.

That contract cannot safely expose organization-owned model configurations. It also does not provide the organization-specific provider information, authorization behavior, ACL management, or recovery guidance needed by the settings and chat clients later in the stack.

Fix

Add organization-scoped chat model endpoints under:

/api/experimental/organizations/{organization}/chats/models

The new API provides:

• Organization-scoped model listing and creation.
• Model get, update, and delete operations scoped by both organization and model ID.
• Model ACL read and update operations.
• Organization-scoped runtime availability and provider status.
• Redacted provider descriptors for model-management clients.
• Chat model RBAC and row ACL enforcement for writes, runtime discovery, and Chatd model selection.
• Recovery guidance when a chat's organization has no usable local model.

Historical chats can retain a model reference owned by another organization, but runtime selection uses an authorized local default when one is available. Foreign, inaccessible, disabled, and otherwise unusable models are not exposed as usable selections for the organization.

The existing collection and availability routes remain as default-organization compatibility endpoints in this layer:

GET  /api/experimental/chats/model-configs
POST /api/experimental/chats/model-configs
GET  /api/experimental/chats/models

These compatibility routes do not provide access to models in non-default organizations. The previous unscoped item update and delete routes are removed because item operations must include the owning organization.

Breaking change

This changes the experimental HTTP API and Go SDK contracts for chat model management.

Clients must migrate model-management and availability requests to the organization-scoped routes and provide an organization identifier. In the Go SDK, the following methods now require an organization ID:

• ChatModelAvailability
• ChatModels
• CreateChatModel
• UpdateChatModel
• DeleteChatModel

ChatModels also changes its return value from []ChatModel to OrganizationChatModelsResponse, which includes the organization models and the redacted provider descriptors required by management clients. New item and ACL methods likewise require both the organization ID and model ID.

The default-organization compatibility routes reduce the immediate impact for collection and availability callers, but they do not preserve the previous item API or SDK method signatures. Generated clients and direct consumers of the experimental API must be updated before adopting this change.

This pull request description was generated by Coder Agents.