feat(agent): 支持受限工具子代理，让子任务能够独立读取与检索证据

[NanaseInori]

用户需要与当前缺口

将代码探索或审查交给子代理后，子代理应能在明确授权的范围内发现缺少的证据，并自行读取文件、搜索符号或回读相关记录，而不是只能分析父代理预先整理的文本。

当前内建 Specialist 是 no-tool 分析路径。这是一个明确的能力缺口，不是已有安全边界失效，也不表示项目完全没有多代理组织、调度或消息能力。

审查基准：0e15d1d104fe535965cf68df50bca6f106f20d52。

影响范围：Go control plane、Specialist Runner、工具网关、子代理权限与持久收据；相关 CLI / HTTP / Desktop 能力投影。

当前代码依据

internal/application/specialist_runner.go：

• specialistRequestWithLayout() 的系统提示明确为 internal no-tool Specialist，禁止请求工具、Shell、网络、凭据和新代理。
• 构造的 ChatRequest 没有提供工具列表。
• validateSpecialistLifecycleResponse() 对任何非空 ToolCalls 返回 response included forbidden tool calls。
• 协议修复路径继续设置 repair.Tools = nil。

internal/llm/harness.go:190–211 的 prepareHarnessRequest() 还会清空非 root workload 的 Tools。因此，只改 Specialist 提示词或取消返回值拒绝仍不足以接通工具；Harness workload/qualification 与 Go 授权入口也要协同处理。

#103 已由 #112 完成 batch delivery 底座，已有 child worktree、缩权工作区工具、邮箱、generation/lease 和交付收据。本项应复用这些边界；现有底座并未给内建 Specialist 接通自主模型工具循环。

因此，当前 Specialist 无法自行完成「发现证据不足 → 获取更多证据 → 继续分析」。增加 Agent 节点或扩大输入文本都不会补齐这条执行路径。

目标场景

父代理将一个范围明确的审查子任务交给 Specialist，例如「追踪鉴权中间件及其测试，指出有代码依据的问题」。子代理根据委托独立读取入口文件、沿调用链检索并读取必要测试，最后返回关联到真实工具收据的结论。

父代理不需要事先读完全部文件或代替子代理发出每次读取。没有取得证据的地方必须如实保留不确定性，不能用报告文字冒充执行结果。

最小可用范围

新增一种显式授权的只读工具子代理类型，保留现有 no-tool Specialist 的默认行为与兼容性。第一阶段固定为 scope 内、有界的 list、read、glob、grep，复用已有工具与路径校验；代码智能/LSP 和所属任务历史回读作为可选后续扩展，不阻塞最小取证闭环。

工具集合由 Go 根据当前 Run、子任务范围、权限、预算和有效 lease 决定，并在调用时重新校验。复用现有工具网关和收据约束，但不能通过伪造 root 身份来绕过只允许 root 的入口。

子任务长期约束与恢复由 #215 跟踪。有工具类型发布前，应联合验证连续多轮后仍保留有效委托；本项不要求一次完成并行写代码、任意 Shell 或递归代理。

验收条件

• 原 no-tool Specialist 行为保持不变，未显式授权时仍不提供工具，也拒绝模型自行请求工具。
• 已授权的只读子代理可完成至少两步取证：根据第一次读取结果选择新的检索/读取，再返回有收据支持的结论。
• 每次工具调用和结果绑定真实的 run、agent、attempt 与工具身份；不能把父代理预先读取的结果伪装成子代理独立执行。
• 越出委托范围、跨子代理读取未授权材料、目录穿越或链接逃逸均被实际网关拒绝。
• 文件修改、任意进程/Shell、网络、凭据访问、审批和派生新代理在首阶段保持不可用，工具输出和 Skill 文本不能授予这些权限。后续若加入受控 LSP，应单独定义固定宿主启动及 scope 边界，不能把受控服务内部进程等同于向子代理开放任意进程执行。
• 子代理 token、工具次数和费用同时受自身及 Run 总预算约束；两名子代理的记录、结果和额度不会混用。
• Stop、权限撤回、lease 过期、数据库重开和未知执行状态有回归；不恢复旧权限，不把历史收据变成新执行授权。
• 与 feat(context): 为 Specialist 保留有效子任务约束，补齐长任务压缩与恢复 #215 联合验证多轮委托持续性；公开能力状态区分 no-tool 与只读工具类型，不把「已提案」显示为「已创建/已执行」。

权限与恢复影响

本项确实新增子代理工具执行能力，需要明确的 Go 授权入口、scope 校验、预算、lease 和持久记录，不是仅修改提示词或删除 ToolCalls 拒绝判断。委托提案本身不等于准入、创建、启动或授权。

实现不应默认继承 root 的全部能力，也不通过笼统放宽现有角色检查来实现；为新 workload 显式接线并保留原 no-tool 类型的拒绝规则。优先复用 #112 的 batch delivery 执行底座及现有网关，新增持久协议或角色类型需有兼容与回滚读取边界。

非目标与证据边界

首阶段不包含写工具、独立 worktree 修改、任意 Shell、递归 spawn 或生产级并行调度。缺口由固定提交的请求构建和结果校验路径确认；本项不声称已完成真实模型自主审查或端到端交付验收。