Show warning for apps/workflows referencing models removed after model‑provider plugin upgrade

### 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] 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] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

When upgrading a model‑provider plugin in Dify Integrations, some models may get removed in the new plugin release.
Existing chatbot applications and workflows which are using those removed models will become incompatible.
Currently there is no overview warning on workspace home page. I have to manually open every single chatbot and workflow one‑by‑one to check broken model references.
This manual checking is very time‑consuming. Worse still, these invalid configurations can only be discovered at runtime when business workflow fails. I hope there can be visual hints to quickly locate all affected resources after plugin upgrade.

### 2. Additional context or comments

Suggested improvements:
1. Add status badge/tag such as `Model unavailable` on workspace list for affected chatbots and workflows.
2. Support filter to list all resources with invalid model configuration.
3. Provide quick‑jump entry to fix the broken configuration directly.

Alternative approach: build a centralized summary page listing application name, resource type, failure reason, related plugin and model, together with repair link.

Environment: Self‑hosted Dify.
Affected resources: Chatbot applications, workflow LLM nodes.

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start at the workspace home page and the chatbot/workflow resource lists, then trace how model-provider plugin upgrades expose removed models and how model configuration is opened. Define one accepted scope—badges and filtering, or a centralized summary with repair links—and verify affected chatbots and workflow LLM nodes are listed with model/plugin failure details and a repair path.

Written by the indexing model from the issue text.