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 不是需求。

third_party/homeagent-sdk/sdk/plugin.go

@@ -311,6 +311,25 @@ type ToolDef struct {
 	// 判据优先级：**Serial 胜出**。显式声明"必须串行"不允许被
 	// ParallelSafe 或任何默认值覆盖。
 	Serial bool `json:"serial,omitempty"`
+	// Timeout 声明本工具单次执行允许的最长时间（如 "2m"、"90s"）。
+	//
+	// ★ 为什么需要它（2026-10-17 生产实测）：
+	//   内核在 agent/core/toolcall.go 里有一个**写死的 60s** 外层上限。
+	//   它与工具自己的超时配置**互相矛盾**且内层形同虚设：
+	//     · cmd_run 有 timeout 参数（默认 30s，可传 "2m"），agent 真的传了
+	//       130s 级的值，但外层 60s 先到 ⇒ 工具自己的设置完全不生效
+	//     · healthcheck 声明默认 120s ⇒ 被砍掉一半
+	//     · 向开发线投递用的 output_send__* 天然是长任务（子 pipeline 执行）
+	//   实测后果：工具被内核掐断，模型看到「执行超时（60秒）」，
+	//   只能换更小的任务重试 —— 而真正的问题是内核没给它足够时间。
+	//
+	// 为零值时的行为：留空 = 用内核默认（60s）。存量插件不改一行，
+	// 行为与改动前逐字一致。声明它是**责任**：写长了要确保工具真能收敛，
+	// 否则会把"卡死"拖得更久。
+	//
+	// 内核会取 min(声明值, 内核硬上限 10m)：防止插件声明成 0（无限）
+	// 或荒唐的大值把队列堵死。
+	Timeout string `json:"timeout,omitempty"`
 }
 
 // IOInjector provides methods for injecting input and interrupts into the agent pipeline.