安全：授权按工具名 call_skill 记，而风险分级按 skillStableName 判——批准一个技能等于批准本 run 内所有 L2 技能

## 缺陷（#3212 排查中实测发现，非推断）

授权的写入与查询用的键是**工具名** `call_skill`：
- 写入：`pg-agent-run-repository.decidePermissionRequest` 用 `RETURNING pending_tool_name`
- 查询：`hasGrant(orgId, runId, interrupted.toolName)`

而 #2767 之后，**风险分级的键是 `skillStableName`**（`call_skill` 的等级按具体技能算，不是按工具名一刀切）。

**后果**：用户对 `web-research` 点「本 run 内都允许」或「以后都允许」，**本 run 内任何其它 L2 技能都会被自动放行**——因为 grant 记在 `call_skill` 这个工具名上，而下一次别的 L2 技能中断报的也是 `call_skill`。

排查该 issue 的 agent **实测确认了这一条**（探针跑 `handleInterruptedToolCall`，写入 run 档 grant 后另一个 L2 技能 `autoApproved: true`）。

## 为什么这条要单独立项

- 它是**授权范围被悄悄放大**，属安全倒退方向，比 #3212 原本要修的「界面看不懂」严重得多。
- 用户看到的授权对象是「web-research」，实际授出的是「这一轮所有高风险技能」——**告知与实际不一致**。
- 修法需要把 `skill_stable_name` 落进 `pending_tool_name` 之外的一列（**数据库迁移**），超出「人类验收期间小而收敛」的边界，所以 #3220 未修，如实留档。

## 又一次「同一事实两个键」

今晚这个形态已第四次出现：
1. L0 白名单写 `web_fetch`，真名 `fetch_url`（#3160）
2. L2 白名单写 `bash_exec`，真名 `execute`（#3160）
3. 注释声称 `write_todos` 在 L0，集合里没有（#3186）
4. **本条：授权按工具名、分级按技能名**

前三条是「名字写错」，这一条是「两个层次用了不同的粒度」——**后果不是不生效，而是范围放大**。

## 交付要求

- **不许为了省事把风险分级改回按工具名一刀切**——那会让所有 skill 退回同一档，是更大的倒退。
- 迁移要考虑存量 grant：既有按 `call_skill` 记的授权在迁移后应当**收窄还是保留**？这是产品/安全裁决，**先给选项和推荐，不要自行决定**。
- 反证必做，且要正反两条：① 批准 A 技能后，同 run 内 B 技能仍然要问；② 批准 A 技能后，同 run 内**再次**调用 A 不再问。

## 关联
#3212（用户观察到重复弹窗，排查中发现本条）、#3220（界面侧修法，未碰本条）、#2767（风险分级改按 skillStableName 的那次变更）。

Trace pg-agent-run-repository.decidePermissionRequest, hasGrant, and handleInterruptedToolCall, then review the existing probe that demonstrated cross-skill auto-approval. First resolve and document the recommended treatment of existing call_skill grants before implementing the migration. Done requires A approval to leave B prompting while allowing repeated A calls without prompting, with both regression cases covered.

Written by the indexing model from the issue text.