Custom model removal can leave stale model credentials and inconsistent provider state

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

1.15.0-main

### Cloud or Self Hosted

Self Hosted (Source)

### Steps to reproduce

1. Add a custom model under a provider that supports model-scoped credentials.
2. Add one or more credentials for that custom model.
3. Remove the custom model.
4. Reopen the model provider page or configuration panel.

Another related path:

1. Have stale model-scoped credentials while the active ProviderModel row is missing or invalid.
2. Open the model configuration modal.
3. Select an existing valid credential.
4. Click Save.

**This is separate from the legacy `model_type` migration issue fixed by #36520/#36704. This report tracks stale custom model credential/provider state after custom model removal or credential switching.**

### ✔️ Expected Behavior

Removing a custom model should also remove its model-scoped credentials and related load-balancing configs.

A removed custom model should not reappear from stale credentials.

When selecting an existing valid credential, Dify should restore the active ProviderModel state and save successfully.

Custom models should not be duplicated because of canonical/legacy provider aliases.

### ❌ Actual Behavior

Removed custom models can still reappear because stale model-scoped credentials remain.

The configuration modal can stay in an inconsistent authorization-removed state.

Saving after selecting another existing credential may fail or not restore the active custom model.

The same custom model can appear more than once when provider aliases are resolved through both canonical and legacy names.

Start at the custom model removal flow and the model configuration modal described in the reproduction steps. Trace how model-scoped credentials, load-balancing configurations, ProviderModel state, and canonical or legacy provider aliases are handled; done means removal leaves no stale state, credential switching saves successfully, and the model is not duplicated or resurrected.

Written by the indexing model from the issue text.