fix: plugin name in the marketplace does not match the local plugin

[Waterwzy]

相关前置PR：#7493

在插件市场获取插件时，获取到的插件分隔符为 - 但是本地插件的metadata全部为 _ 会导致插件名称的匹配问题。

同时，在检查插件更新时，checkUpdate() 在 getExtensions() 中被调用时， pluginMarketData （远程插件市场数据）尚未加载完成，导致匹配时 ·pluginMarketData· 为空，无法找到匹配的远程插件。

本PR通过修改获取插件市场插件的时机，在后端API接口统一插件名称的方式解决了这些问题。

Modifications / 改动点

1. 后端 ( astrbot/dashboard/routes/plugin.py )
   修改了 3 个接口方法，增加了用于插件市场的插件名称：

• get_plugins() - 返回本地插件列表
• get_plugin_detail() - 返回插件详情
• get_plugin_page_components() - 返回插件页面组件信息

2. 前端 ( dashboard/src/views/extension/useExtensionPage.js )

• 调整 checkUpdate() 调用时机 ：

  • 从 getExtensions() 中移除调用（避免在 pluginMarketData 加载前执行）
  • 在 finalizeSuccessfulInstall() 中添加调用（确保安装后立即检查更新）

• 清理 checkAlreadyInstalled() 函数 ：移除不再需要的 replace(/_/g, "-") 操作

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

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

当插件repo不匹配但是名称匹配时：

检查是否安装和是否更新的行为均按预期进行。

---

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

Align plugin name handling between local metadata and marketplace data to ensure consistent matching and correct update checks.

Bug Fixes:

• Fix plugin installation and update detection when marketplace plugin names use dashes and local plugin metadata uses underscores.
• Ensure update checks run only after marketplace plugin data has been loaded to avoid missing remote matches.

Enhancements:

• Expose normalized marketplace-oriented plugin names from backend plugin APIs for consistent frontend matching.
• Use marketplace-specific names in frontend matching logic when determining installed and updatable plugins.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The API is now mixing marketplace_name and plugin_marketplace_name keys (e.g., in get_plugin_page_components vs get_plugins / get_plugin_detail); consider standardizing on a single field name to avoid confusion and subtle frontend mapping bugs.
• The underscore-to-dash transformation for plugin names (plugin.name.replace('_', '-')) is duplicated across multiple backend endpoints; consider extracting this into a helper or property to keep the normalization logic centralized and less error-prone if the rule ever changes.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The API is now mixing `marketplace_name` and `plugin_marketplace_name` keys (e.g., in `get_plugin_page_components` vs `get_plugins` / `get_plugin_detail`); consider standardizing on a single field name to avoid confusion and subtle frontend mapping bugs.
- The underscore-to-dash transformation for plugin names (`plugin.name.replace('_', '-')`) is duplicated across multiple backend endpoints; consider extracting this into a helper or property to keep the normalization logic centralized and less error-prone if the rule ever changes.

## Individual Comments

### Comment 1
<location path="astrbot/dashboard/routes/plugin.py" line_range="1273-1275" />
<code_context>
                 logo_url = await self.get_plugin_logo_token(plugin.logo_path)
             _t = {
                 "name": plugin.name,
+                "marketplace_name": plugin.name.replace(
+                    "_", "-"
+                ),  # 用于市场匹配的名称（减号格式）
                 "repo": "" if plugin.repo is None else plugin.repo,
                 "author": plugin.author,
</code_context>
<issue_to_address>
**suggestion:** Extract repeated marketplace name normalization into a helper

This normalization logic is now repeated in `get_plugins`, `get_plugin_detail`, and indirectly in `get_plugin_page_components` via `plugin_marketplace_name`. Please extract it into a small helper (e.g. `normalize_marketplace_name(plugin.name)`) so future changes only need to be made in one place.
</issue_to_address>

---

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.}

[sourcery-ai]

suggestion: Extract repeated marketplace name normalization into a helper

This normalization logic is now repeated in get_plugins, get_plugin_detail, and indirectly in get_plugin_page_components via plugin_marketplace_name. Please extract it into a small helper (e.g. normalize_marketplace_name(plugin.name)) so future changes only need to be made in one place.

[gemini-code-assist]

Code Review

This pull request introduces a marketplace_name field for plugins, standardizing the name format by replacing underscores with hyphens to improve marketplace matching. The frontend logic in useExtensionPage.js has been updated to utilize this new field and normalizeStr for more robust plugin identification and installation status checks. Feedback from the review highlights the need for safe access to plugin.name in the backend to prevent potential AttributeError exceptions and suggests refactoring the name-formatting logic into a shared helper function. Additionally, it was noted that the installedByName mapping in the frontend should use normalized keys to ensure consistent case-insensitive matching.

[gemini-code-assist]

installedByName 映射的键应使用 normalizeStr 进行归一化，以确保大小写不敏感的匹配，这与 checkUpdate 中处理 onlinePluginsNameMap 的方式一致。请注意，1257 行（目前在此 diff 之外）的查找逻辑也需要同步更新为使用 normalizeStr(plugin.name) 才能正确匹配。