fix(scheduler)!: 撤掉“优先级=可配置策略表”的错误设计，回归内核内部属性

用户指正：**优先级是内核内部属性**，不是配置项，更不该由插件声明。
我此前把它建模成“策略表 + 字符串解析”，甚至准备接配置中心
（core.agent.priority.<channel>）——方向性错误，故整体撤销。

撤销：
- 删除 ParseLevel（字符串解析只服务于“外部可配”这个错误前提）
- 删除 AgentConfig.PriorityLookup / Agent.priorityLookup 及 taskLevel 中的查表分支；
  taskLevel 回归为纯内核内部规则（cli/webui/http→L3，system/_consolidation_→L1，
  其余 L1），注释明确“不对外暴露、不做运维可调项”
- 设计稿 §3.2 改写为“内核内部属性，不做成配置项”，并删除 §15 里
  “ChannelDef.Priority / InjectOptions.Priority 进公开 SDK”这一方向（同属外化）
- 未触碰配置中心（registry.go/main.go 的优先级配置一行未加）

同时落地 D6（与本撤销无关、此前遗漏的承诺）：
- AgentConfig.MaxToolTurns + runTaskSteps 在发起新一轮 LLM 前按 f.Turn 收尾；
  0 = 不限；cmd/homed/main.go 从既有 core.agent.max_tool_turns 取值
- 新增 task_test.go 2 项：上限 3 时恰好跑 3 批工具/3 次 LLM 并收尾；
  0 = 不限（跑完脚本）

验收：agent 全量 + -race；全仓 build/vet 通过

internal/agent/core/agent.go

@@ -114,8 +114,8 @@ type Agent struct {
 	// M2 起取代 eventLoop 的隐式 channel 排队。
 	sched *scheduler
 
-	// 优先级策略表（可空）；见 AgentConfig.PriorityLookup。
-	priorityLookup func(source, channel string) Level
+	// 工具轮次硬上限（0 = 不限）；见 AgentConfig.MaxToolTurns。
+	maxToolTurns int
 
 	// 进行中的 LLM 请求取消函数，interceptLoop 可调用以在请求中打断
 	cancelLLM context.CancelFunc
@@ -224,9 +224,9 @@ type AgentConfig struct {
 
 	InputProcessing types.InputProcessingConfig // 非文本输入处理配置
 
-	// PriorityLookup 是内核的优先级策略表（设计文档 §3.2）。
-	// 返回 L1..L4；返回 0 或越界值表示“无策略”，由 Agent 的通道名兜底决定。
-	PriorityLookup func(source, channel string) Level
+	// MaxToolTurns 是单个任务允许的工具轮次上限（0 = 不限）。
+	// 设计文档 D6：主循环必须有硬上限，否则模型不停调用就永不完结。
+	MaxToolTurns int
 }
 
 func New(cfg AgentConfig) *Agent {
@@ -310,7 +310,7 @@ func New(cfg AgentConfig) *Agent {
 		selfInputCh:       make(chan selfInputMsg, 64),
 		childTasks:        make(map[string]*childTaskState),
 		sched:             newScheduler(256),
-		priorityLookup:    cfg.PriorityLookup,
+		maxToolTurns:      cfg.MaxToolTurns,
 		pluginHealth:      newPluginHealthTracker(),
 		thinkingEnabled:   cfg.ThinkingEnabled,
 		inputCfg:          cfg.InputProcessing,