refactor(webui): 7 个黑箱判据迁到 test/ + 导出前端资源入口

## 迁移了什么

    chat_ack_timeout_test.go       → test/
    chat_attachment_img_test.go    → test/
    cmd_history_render_test.go     → test/
    config_namespace_test.go       → test/
    dashboard_tabs_deps_test.go    → test/
    plugin_status_render_test.go   → test/
    starmap_perf_test.go           → test/

包名 `webui` → `test`。`webui/` 目录少 7 个测试文件。

## 为什么是这 7 个（分类依据）

先按「对未导出符号的依赖数」把 29 个测试文件测了一遍，这 7 个是
**0 依赖**（既不用 handleXxx，也不用 testSDK/newTestHandler 等测试辅助）。
其余 22 个按强度递增留在包内，后续逐步处理。

## 新增两个导出入口

### webui.FrontendAsset(name)

返回打包进二进制的前端资源原文（dashboard.js / dashboard.css /
mascot.webp / logo.svg …）。

判据要检查「实际会被发出去的那份文本」：dashboard.js 在严格模式下
会不会抛 ReferenceError（用 node 真跑）、mascot.webp 的魔数是否合法、
HTML 属性里有没有残留转义引号。

这些无法通过 HTTP 端点可靠断言（要登录态、且拿到的是拼接后整页，
定位不到单个 asset）。而留在包内测就得读 `dashboardFS` 这个**未导出变量**
—— 那正是"测试耦合实现"。导出后，判据变成「输入 asset 名 → 输出字节」，
与资源存在哪个变量、怎么 embed 无关。

### webui.DashboardPage()

返回组装完成的整页 HTML（外壳 + 内联 CSS/JS）—— 浏览器实际收到的那份。
与 FrontendAsset 的分工：那个取单个源资产，这个取成品。

## 顺带修掉迁移暴露的两个隐患

① 三个判据原本 `os.ReadFile("dashboard.js")` 读**磁盘相对路径**。
   在包内恰好能跑（工作目录就是包目录），但那读的是**工作区文件**，
   不是**二进制里实际嵌入的那份** —— 两者在生产上可能不同
   （比如打包后 dashboard.js 被替换）。统一改走 FrontendAsset。

② starmap_perf_test 的相对路径 `../../../shared/starmap/layout.js`
   与 `static/starmap-layout-worker.js` 在移入子目录后失效，已修正为
   `../../../../shared/...` 与 `../static/...`。

## 判据仍有效（变异验证）

把 dashboard.js 里 ack 超时 `}, 600000);` 改成 `}, 30000);`：

    --- FAIL: TestChatAckTimeoutIsGenerous
        ★ 受理超时只有 30000 ms —— 太小。
          超时太短会让前端 abort，而 agent 仍在正常干活

恢复后全绿。迁移不是搬完就废。

## 验证

    go build ./...            PASS
    go vet ./...              PASS
    gofmt -l                  干净
    go test ./... -count=1    63 包全过，0 FAIL
                             （webui/test 是新包，故 62 → 63）
    干净检出（worktree）       build + webui/... 全绿

## 后续

    webui 剩余 22 个文件（依赖 handleXxx / testSDK 等），按强度递增处理
    agent/core 739 处白盒引用，先分类再动
    CI 补 coverage + staticcheck

internal/plugins/webui/handler.go

@@ -80,6 +80,34 @@ document.getElementById('login-form').addEventListener('submit',async(e)=>{e.pre
 document.getElementById('password').addEventListener('keydown',function(e){if(e.key==='Enter')document.getElementById('login-form').dispatchEvent(new Event('submit'))});
 </script></body></html>`
 
+// FrontendAsset 返回打包进二进制的前端资源原文
+// （dashboard.js / dashboard.css / dashboard.html / mascot.webp / logo.svg）。
+//
+// ## 为什么需要导出（2026-11-04）
+//
+// 前端刻意没有构建链 —— 资源经 go:embed 进二进制。判据要检查的是
+// 「**实际会被发出去的那份文本**」：dashboard.js 在严格模式下会不会抛
+// ReferenceError、mascot.webp 的魔数是否合法、剥离 HTML 后的属性里
+// 有没有残留转义引号。
+//
+// 这些无法通过 HTTP 端点可靠断言（要登录态、且拿到的是拼接后的整页，
+// 定位不到单个 asset）。而留在包内测就得读 `dashboardFS` 这个未导出变量
+// —— 那正是"测试耦合实现"的形态。
+//
+// 导出它，测试就能以「输入 asset 名 → 输出字节」断言，
+// 与资源存在哪个变量、怎么 embed 完全无关。
+func FrontendAsset(name string) ([]byte, error) {
+	return dashboardFS.ReadFile(name)
+}
+
+// DashboardPage 返回**组装完成的控制台整页**（外壳 + 内联 CSS/JS）。
+//
+// 这是浏览器实际收到的那份 HTML。与 FrontendAsset 的分工：
+// 那个取单个源资产，这个取组装后的成品。两者都是对外产物。
+func DashboardPage() string {
+	return dashboardHTML
+}
+
 // dashboardHTML 是组装好的控制台页面：dashboard.html 外壳 + dashboard.css + dashboard.js。
 //
 // 前端刻意没有构建链，所以拆分的办法是：外壳里留 {{DASHBOARD_CSS}} / {{DASHBOARD_JS}}