fix(agent): 工具超时不再一刀切 60s，支持工具自声明与按参数推导

## 缺陷（2026-10-17 生产日志实测）

`toolcall.go` 里写死 `time.After(60 * time.Second)`，与工具自己的超时
**互相矛盾**且让内层形同虚设：

	23:13:38  执行 cmd_run（agent 传了 timeout="130" 级参数）
	23:14:38  ★ 内核 60s 硬超时掐断 → 「执行超时（60秒）」

同一份日志里 healthcheck 声明默认 120s ⇒ 被砍掉一半，天生跑不完。

## 改动

1. `ToolDef.Timeout` / `BuiltinToolDef.Timeout`：工具自己声明单次上限。
   留空 = 沿用 60s（存量插件**一行不改，行为逐字不变**）。

2. 内核取 `max(声明值, 调用参数 timeout)`，再夹到硬上限 10m：
   · 声明修好固定时长的工具（healthcheck 5m）
   · 参数推导修好时长可变的工具（cmd_run 的 timeout 参数）
   · 硬上限防插件声明成 0/无限把队列堵死

3. 非法声明（"130" 少单位、0s、负数）**回退默认并记日志**，不静默接受。
   写错单位是最容易犯的错，默默变成 60s 会让人以为"声明没生效"却查不出。

4. healthcheck 声明 5m（它的 llm_timeout 默认就是 120s）。

★ 没有把 timeout 放进 `ToSchema()`：那份 map 是**发给模型**的 function
  schema。把内核的执行参数混进去，模型会以为需要自己传 timeout 参数。

## 判据（6 条）

未声明→60s / 声明生效 / 参数参与取 max / 参数比声明小用声明 /
非法回退 / 超上限夹住。变异全部咬住。

## 附：这条路只治「工具真的需要更久」

向开发线投递（output_send__*）的两次 60s 超时**不是这个原因** ——
那是 commondev 把"投递"实现成了"同步等任务完成"，已在 SDK 仓修成异步。
这里没有给 output_send 放大超时：投递应该瞬时返回，慢是 bug 不是需求。

internal/agent/core/tooldefs.go

@@ -306,9 +306,39 @@ func (a *Agent) buildToolCatalog() string {
 //     工具改名不会跟着变；
 //  2. 往 required 变参里塞字符串 "toolParallel" —— 拼错就静默失效，
 //     编译器不报错，而"少一个工具能并发"正是最难察觉的那类问题。
+//
+// builtinToolTimeouts 是内置工具声明的执行超时（name → 如 "3m"）。
+//
+// 只在 init 阶段（buildToolDefs 首次调用）写入，之后只读 ⇒ 无需加锁的
+// 前提是"写发生在任何并发读之前"。为稳妥起见用 RWMutex：buildToolDefs
+// 可能被多次调用（每轮重建工具表），而 resolveToolTimeout 在工具执行时读。
+var (
+	builtinToolTimeoutMu sync.RWMutex
+	builtinToolTimeouts  = map[string]string{}
+)
+
+func registerBuiltinToolTimeout(name, d string) {
+	builtinToolTimeoutMu.Lock()
+	builtinToolTimeouts[name] = d
+	builtinToolTimeoutMu.Unlock()
+}
+
+// builtinToolTimeout 查内置工具声明的超时（"" = 未声明）。
+func builtinToolTimeout(name string) string {
+	builtinToolTimeoutMu.RLock()
+	defer builtinToolTimeoutMu.RUnlock()
+	return builtinToolTimeouts[name]
+}
+
 type toolDefOptions struct {
 	// parallel 声明该工具可被并发执行（已核实只读、无共享写）。
 	parallel bool
+	// timeout 声明该工具单次执行的最长时间（如 "3m"）。
+	//
+	// ★ 为什么需要（2026-10-17 生产实测）：内核原本把所有工具一刀切 60s，
+	// 而 output_send__* 是**投递到子 pipeline** 的长任务，天然可能超过 60s
+	// （实测两次 60s 超时）。留空 = 用内核默认 60s，行为不变。
+	timeout string
 }
 
 // parallelOpts 是"可并发"的声明项。
@@ -332,6 +362,17 @@ func toolDefWith(name, description string, properties map[string]interface{}, re
 		Description:  description,
 		Parameters:   params,
 		ParallelSafe: opts.parallel,
+		Timeout:      opts.timeout,
+	}
+	// ★ 内置工具不走 StageHost.RegisterTool（它们由 executeToolCallInner
+	// 的 switch 分派），所以 Timeout 声明若只留在结构体上就没人读得到。
+	// 这里顺手登记进包级表，供 resolveToolTimeout 查询。
+	//
+	// 为什么不在 ToSchema 里带上 timeout：那份 map 是**发给模型的**
+	// function schema。把内核的执行参数混进去，模型会以为需要自己传
+	// timeout 参数，反而制造新的误解。
+	if opts.timeout != "" {
+		registerBuiltinToolTimeout(name, opts.timeout)
 	}
 	return def.ToSchema()
 }