[flaky] skill-agent-import-usecase-audit.spec.ts④ chat-skill-mounted 挂载点在 fullstack-smoke 上偶发渲染出两个同 testid 节点（strict mode violation）

## 现象

`e2e/skill-agent-import-usecase-audit.spec.ts:282` （④ 在 chat 输入框敲 `#` 弹出 skill
候选并可选中挂载）在 CI `fullstack-smoke`（`seeded-github-import` project）上间歇性失败：

```
Error: expect(locator).toBeVisible() failed
Locator: getByTestId('chat-skill-mounted-${mountableSkillId}')
Error: strict mode violation: resolved to 2 elements
```

同一个 `data-testid` 渲染出两个节点。断言处：

```ts
// line 306
await expect(page.getByTestId(`chat-skill-mounted-${FULLSTACK_E2E.mountableSkillId}`)).toBeVisible();
```

## 复现记录

- 2026-08-28，PR [#2314](https://github.com/boardx/workspacex/pull/2314)：同一条用例在
CI 上连续两次 rerun 都以完全相同的 testid、完全相同的错误签名失败（两次分别失败在
`skill-467-no-...` / `skill-467-pr-...`，只是种子 skillId 后缀不同，说明每次跑的
fixture 都会重新生成 mountableSkillId，不是数据脏了，而是同一条断言本身间歇性判两个
节点）。
- 该 PR 新增的 5 条 core-journey spec（本身也在 `seeded-github-import` project 里跑）
全部稳定通过，两次 CI 跑都是 60/61，唯一红的都是这一条——可判定与该 PR 改动无关。
- 历史上 #1608（已关闭）记录过同一文件 `:239`（③ 真实试跑）在 fullstack-smoke 上的
间歇超时，是另一处断言、另一个症状，但同一个文件、同一个 project 里已经不是第一次
在 CI 上偶发失败——怀疑这个 project 的 CI 时序容忍度整体偏紧，值得作为一类问题看。

## 疑似根因方向（未验证，留给认领的人）

`chat-skill-mount` 点击后大概率先走一次乐观 UI 插入 chip，再等 `POST
/threads/:id/skill-mounts` 201 响应后由服务端状态再插入/替换一次——如果这两次插入
没有做 key 去重（例如乐观插入用临时 id、确认后用服务端 id，短暂窗口内两个 chip 都在
DOM 里），就会在这个窗口内被 5s 超时的 `toBeVisible` 断言撞上。建议先读
`apps/web/components/chat` 里挂载 skill chip 的组件，找乐观更新与服务端确认之间是否
有去重逻辑。

## 影响

目前只在 CI 观测到，本地跑（`with-test-isolation.ts`）多轮未复现——像是 CI 环境更慢，
把一个本地测不出来的窄时间窗放大成偶发可见。

Start at e2e/skill-agent-import-usecase-audit.spec.ts around lines 282-306, then inspect apps/web/components/chat for the skill-chip optimistic update and server-confirmation flow. Run the fullstack-smoke seeded-github-import project to observe the failure. Done means one mounted-skill testid remains in the DOM and the assertion passes reliably in CI.

Written by the indexing model from the issue text.