fix: hide and reject chat models from disabled AI providers - #27070

… info

The user provider key configs endpoint omits disabled providers unless
the user has a key for them, so a missing provider row means the
provider is disabled or deleted. Treating missing rows as enabled let
admins select models under a disabled provider whenever another enabled
provider of the same type kept the catalog type available.

The Coder Agents settings page filters model configs by provider
enablement, but only reported the model config query's loading and
error state. While the provider query was still loading or after it
failed, the filter saw an empty provider map and hid every model, which
made saved subagent and advisor overrides look unavailable and could
let AdvisorSettings clear a valid override on save. Combine both
queries' loading, fetching, and error state so the sections stay in
their loading or error UI until provider data is ready.

The add-model page derives its provider selection from the ?provider=
query param, and canManageProviderModels did not check provider
enablement, so a disabled provider stayed selectable and the form could
submit a create request the backend rejects. Treat disabled providers
as unmanageable, keep the selected disabled provider visible only in
edit mode, and explain the disabled state in the add-page fallback.

When a chat omitted model_config_id, admission reused the chat's last
model via a lookup that only excluded deleted configs, so chats whose
model or provider was disabled kept sending requests through the
disabled provider. Resolve the fallback through the enabled-config
lookup: a disabled last model now falls back to the default, and a
disabled default is rejected with ErrNoDefaultChatModelConfig instead
of being admitted and failing at generation time.

Creating a chat without model_config_id resolved the default model
without checking that it and its provider are enabled, so disabling the
default model's provider let POST /chats create a running chat that
only failed later at generation time. Validate the resolved default
through the enabled-config lookup and reject the request with a 400 at
admission, matching the send-message fallback behavior.

Editing a message without model_config_id preserved the edited
message's original model without checking that it is still usable, so
edits kept routing through disabled models or providers and failed at
generation time. Resolve the preserved model through the send-message
fallback (disabled model falls back to the default, disabled default is
rejected) and map the rejection to a 400 in the edit handler.