fix(plugin): 修两处持锁自死锁（CI 双红真因）+ tools_ready 事件声明

## 死锁（这是 CI 连续两次红的真因）

`StopAll` 与 `StopPlugin` 都在持有 `r.mu` **写锁**时调用
`RemoveBuiltinSkill` → `skillDirOf` → `r.mu.RLock()` ⇒ **自死锁**。

后果不是报错而是**卡死**：
- internal/plugins 卡 300s 超时（TestCapability_RestrictedPluginStillLoads）
- internal/plugin  卡 840s 超时（TestStopPluginDoesNotTouchPersistentState）
- CI 的 `go test ./...` 与 `go test -race` 双双红

修法：拆出**不加锁**的内部版本，持锁路径只走它：
- `skillDirFrom(dataDir, name)`（纯函数）
- `removeBuiltinSkillLocked(pluginName, p, dataDir)`（显式传 dataDir，
  避免"看起来没取锁、一改就取锁"的隐患）
- `announceSkillRemovedLocked`（持锁下直读 r.evBus）

修后：internal/plugins 300s → 12s，internal/plugin 840s → 0.7s。

## 防回归判据

`TestStopAllAndStopPluginDoNotDeadlock`：死锁**不返回**，普通断言抓不到，
所以用**超时**当判据（5 秒未返回即失败），并指明应改用 Locked 版本。

## tools_ready 事件声明

新增的 tools_ready 触发 `TestEveryPublishedEventHasAnOutwardPath`
（该判据防"事件发了、客户端收不到"的静默失效）。

tools_ready 是**内核内部**就绪信号（plugin-host → seq 等订阅者），
不是对话流程事件，前端无需感知 ⇒ 在 allowed 里显式声明理由。

## 验证

go build ./... / go vet ./... / go test -p 1 ./... / -race 全通过。

internal/plugins/seq/skill.go

@@ -39,21 +39,35 @@ func (p *Plugin) BuiltinSkills() map[string]string {
 // 它才是注入系统提示词的那一行。
 const seqSkillMarkdown = `---
 name: seq-tools
-description: 把反复出现的同类工具操作编成序列存起来，以后一次执行。
+description: 把反复出现的同类工具操作编成序列存起来，以后一次执行。仅适合要反复跑同一套流程的批处理。
 ---
 
-把反复出现的同类工具操作编成「序列」存起来，以后一次执行：组内并行、组间串行，可带条件判断与变量槽引用。
+把反复出现的同类工具操作编成「序列」存起来，以后一次执行。只适合**要反复跑同一套流程**的批处理场景；一次性的事直接调工具更快。
 
-## 什么时候用
+## 什么时候用（**多数时候不该用**）
 
-**看到下面任一情形，先想一下要不要用序列：**
+序列是**批量脚本**工具，不是常规调用方式。常见做法是直接调工具，那是对的。
 
-- 你要连续做几件**顺序已知**的事（例：拉日志 → 过滤 → 汇总 → 发通知）。
-- 同样一套操作要在**多个对象**上重复（例：对 5 个仓库各跑一次同样的三步检查）。
-- 某套流程**以前做过**，这次还要再做一遍 —— 先用 ` + "`seq_list`" + ` 看有没有现成的，直接 ` + "`seq_run`" + `。
-- 一轮里要调的工具很多、参数很长 —— 编成序列可以写成文件（` + "`seq_create`" + ` 的 file 参数），避免参数被长度上限截断。
+**真的划算只有一种情形：同一套流程要被反复执行。**
 
-**不适合**：只有一两个工具、或后一步依赖前一步的**实际返回值**（那种要分多轮）。
+判据是「这套东西**以后还要跑第二遍、第三遍**吗」：
+
+- ✅ 每天/每周都要做的固定检查（拉日志 → 过滤 → 汇总 → 发通知）
+- ✅ 同一套操作要在**很多对象**上跑（对 20 个仓库各跑同样四步）；对象越多越划算
+- ✅ 参数很长、容易超长度上限 —— 写成文件（` + "`seq_create`" + ` 的 file 参数）
+- ✅ 上次已经编过 —— 用 ` + "`seq_list`" + ` 找现成的，` + "`seq_run`" + ` 直接跑
+
+**不划算（直接调工具更快）：**
+
+- ❌ **只做一次**的事。先 ` + "`seq_create`" + ` 写序列再 ` + "`seq_run`" + `，比直接调多两步
+- ❌ 只有两三个工具。省不下时间
+- ❌ 几个工具可以**同批并行**发出（如同时读 5 个文件）—— 那已经是最优路径，
+  包进序列只是多一层壳
+- ❌ 后一步要依赖前一步的**实际返回值** —— 组内并行拿不到彼此结果，得拆组，不如分多轮
+
+> 曾经有过「应该多用序列」的说法，但实测不成立：对一次性的多文件读，
+> 模型直接并行 ` + "`files_read`" + ` 就是最优解，包成序列纯亏。
+> 所以这份文档的第一句话就是"多数时候不该用"。
 
 ## 核心概念