fix(coderd): allow deleting chat providers used in historical chats (#24568)

Drop the `chat_model_configs.provider -> chat_providers.provider`
foreign key and soft-delete model configs when their provider is
removed. The provider row is now hard-deleted inside a transaction that
also tombstones its model configs and promotes a replacement default
when needed.

Historical chats and messages keep pointing at the soft-deleted model
config rows, which are hidden from live/admin queries but still resolve
for read. The runtime chat path already falls back to the default model
config when a soft-deleted config is looked up.

Replaces the lost FK validation in the create/update model-config
handlers with an explicit provider lookup that returns the existing
`Chat provider is not configured.` 400.

## UX

**Admin deleting a chat provider that has historical usage**

- Before: blocked with 400 `Provider models are still referenced by
existing chats.` Admins had no in-product way to remove a provider that
had ever been used.
- After: delete succeeds (204). Any model configs under that provider
are soft-deleted. If the removed provider owned the default model
config, one of the remaining live configs is auto-promoted to the new
default. The promotion is deterministic (`ensureDefaultChatModelConfig`
picks the first live config by `provider ASC, model ASC, updated_at
DESC, id DESC`); there is no picker, and no toast or response detail
names which config became the new default.

**End users with chats that used a deleted provider's model**

- Old chats still open and their history still renders unchanged.
- Sending a new turn in such a chat silently falls back to the current
default model. No banner or warning tells the user the original model is
gone.
- The model picker no longer lists the deleted model.
- If no default model config exists at all after the delete, sending a
new turn fails with `no default chat model config is available`.

**Admin creating or updating a model config against a provider that is
not configured**

- Same as before: 400 `Chat provider is not configured.` Only the
detection mechanism changed (explicit `FOR UPDATE` lookup inside the
transaction, which also serializes against a concurrent provider
delete).

**Admin updating a model config whose row disappears mid-transaction**

- Now returns the standard 404 `Resource not found or you do not have
access to this resource` instead of the previous 500 that leaked `sql:
no rows in result set` in the detail. Unrelated internal races (for
example a race on the promoted default candidate) are still reported as
500 so they are not misclassified as "your target is gone".

Closes CODAGT-23

coderd/database/migrations/000474_drop_chat_model_config_provider_fk.down.sql

@@ -0,0 +1,27 @@
+-- Restore placeholder provider rows before re-adding the provider FK.
+--
+-- The companion up migration dropped chat_model_configs.provider's foreign
+-- key, so historical model-config rows can outlive a deleted provider row.
+-- These backfilled providers are deliberately disabled stubs with empty
+-- credential fields, which lets rollback restore referential integrity
+-- without re-enabling a provider. This insert depends on the current
+-- provider whitelist still admitting every historical
+-- chat_model_configs.provider value, and on the omitted columns keeping
+-- compatible defaults. Operators restoring a real provider should update the
+-- stub row, including credential-policy flags such as
+-- central_api_key_enabled, before enabling it, rather than insert a second
+-- row with the same provider name.
+INSERT INTO chat_providers (provider, enabled)
+SELECT DISTINCT
+    cmc.provider,
+    FALSE
+FROM
+    chat_model_configs cmc
+LEFT JOIN
+    chat_providers cp ON cp.provider = cmc.provider
+WHERE
+    cp.provider IS NULL;
+
+ALTER TABLE chat_model_configs
+    ADD CONSTRAINT chat_model_configs_provider_fkey
+    FOREIGN KEY (provider) REFERENCES chat_providers(provider) ON DELETE CASCADE;

coderd/database/migrations/000474_drop_chat_model_config_provider_fk.up.sql

@@ -0,0 +1,2 @@
+ALTER TABLE chat_model_configs
+    DROP CONSTRAINT chat_model_configs_provider_fkey;