fix: heal stale plugin sidebar entries when plugin page errors out

[lxfight]

Motivation / 动机

侧边栏的“插件 WebUI”分组由模块级共享状态（pluginSidebarState）驱动，仅在首次挂载或扩展页操作时刷新。若插件在当前会话之外被卸载/禁用（其他标签页、CLI、直接调用 API），侧边栏仍会渲染该插件的入口，用户点击后进入错误页，直到访问扩展页才恢复同步。

Modifications / 改动点

• dashboard/src/views/PluginPagePage.vue：loadPluginPage() 发现目标插件不存在时，从共享状态中移除该插件的陈旧入口；发现插件被禁用时，将共享状态中对应条目标记为 activated: false。侧边栏已有的 watch 会立即响应数组引用变化并重建菜单项。

• 采用“发现即修复”策略：无轮询、无定时器，仅在陈旧状态真正暴露（用户点击陈旧入口）时精确修正。

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

$ cd dashboard && pnpm typecheck
vue-tsc --noEmit  # passed, no errors

验证步骤：

1. 打开 Dashboard，确认侧边栏出现某插件的 WebUI 入口。
2. 在另一个标签页（或通过 API）卸载/禁用该插件。
3. 回到原标签页点击侧边栏该入口 → 显示“插件不存在/未启用”错误的同时，侧边栏分组中该入口立即消失，无需手动刷新。

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Synchronize plugin sidebar state when plugin pages reveal that plugins were removed or disabled, while guarding against stale route-load responses.

Bug Fixes:

• Remove stale plugin sidebar entries when a plugin is missing and mark entries inactive when a plugin is disabled.
• Prevent outdated asynchronous plugin page responses from overwriting current view or sidebar state.

Tests:

• Verify the dashboard passes the TypeScript typecheck without errors.

[sourcery-ai]

Hey - I've found 2 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="dashboard/src/views/PluginPagePage.vue" line_range="575-579" />
<code_context>
     const pluginData = detailResponse.data?.data || null;
     if (!pluginData) {
       errorMessage.value = tm("messages.pluginNotFound");
+      // 修正侧边栏共享状态中已卸载插件的陈旧入口
+      pluginSidebarState.plugins = pluginSidebarState.plugins.filter(
+        (p) => p.name !== pluginName.value,
+      );
       return;
     }

</code_context>
<issue_to_address>
**issue (broader_impact):** The stale-entry repair is skipped when the missing-plugin API responds with an error envelope or an HTTP error: the function throws or enters the existing catch before reaching the `!pluginData` branch, so the sidebar entry remains visible after the user opens it.

**Triggers:** When the backend reports a missing plugin as `status: "error"` or a non-2xx response instead of returning `status: "ok", data: null`.

**Suggested fix:** Handle the missing-plugin response/error before rethrowing, or perform the sidebar removal in the error path when the error identifies the requested plugin as missing.
</issue_to_address>

### Comment 2
<location path="dashboard/src/views/PluginPagePage.vue" line_range="575-579" />
<code_context>
     const pluginData = detailResponse.data?.data || null;
     if (!pluginData) {
       errorMessage.value = tm("messages.pluginNotFound");
+      // 修正侧边栏共享状态中已卸载插件的陈旧入口
+      pluginSidebarState.plugins = pluginSidebarState.plugins.filter(
+        (p) => p.name !== pluginName.value,
+      );
       return;
     }

</code_context>
<issue_to_address>
**issue (bug_risk):** An older `loadPluginPage` request can mutate the sidebar entry for a newer route because the mutation compares against `pluginName.value` after an `await` rather than the plugin name used when that request started. Navigating from plugin A to plugin B while A's request is pending can therefore remove or deactivate B's sidebar item.

**Triggers:** When the user changes plugin routes before the previous `pluginApi.get` request resolves.

**Suggested fix:** Capture the route plugin name at the start of `loadPluginPage` and only mutate shared state if it still matches the current route, or cancel/sequence obsolete requests.
</issue_to_address>

Sourcery assessment

Approval pending. 2 findings to address first.

Blocking findings: dashboard/src/views/PluginPagePage.vue:579, dashboard/src/views/PluginPagePage.vue:579

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}