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/scheduler.go

@@ -66,6 +66,13 @@ func (l Level) String() string {
 	}
 }
 
+// ParseLevel 已删除。
+//
+// 为何不保留：优先级是**内核内部属性**，不是配置项——内核预定义四级
+// （L1 后台 / L2 消息 / L3 交互 / L4 紧急），由内核按内部规则为任务与中断定级。
+// 曾一度做成 `core.agent.priority.<channel>` 这种“策略表 + 字符串解析”，
+// 那等于把内核的内部属性外化成运维配置，与设计意图相反。
+
 // TaskKind 区分任务来源。
 type TaskKind int
 
@@ -471,17 +478,15 @@ func (s *scheduler) currentLevel() Level {
 	return DefaultLevel
 }
 
-// taskLevel 是内核的优先级策略：四级的来源（设计文档 §3.2）。
+// taskLevel 是内核为任务定级的内部规则。
 //
-// 优先走注入的查找函数（配置表）；未命中则用通道名兜底：
-// cli/webui/http 为人机交互（L3），system/_consolidation_ 为后台（L1），
-// 其余一律默认级（L1）。显式才是特权：没有策略就不给抢占权。
+// ❗优先级是**内核内部属性**，不做成配置项：内核预定义四级，并按内部规则
+// 为任务与中断定级。下方规则只是 v1 的内部缺省值——它决定“谁能让位于谁”，
+// 属于内核自己的隐私，不对外暴露为运维可调项。
+//
+// 缺省：cli/webui/http 为人机交互（L3），system/_consolidation_ 为后台（L1），
+// 其余一律默认级（L1）。
 func (a *Agent) taskLevel(source, channel string) Level {
-	if a.priorityLookup != nil {
-		if l := a.priorityLookup(source, channel); l >= LevelBackground && l <= LevelCritical {
-			return l
-		}
-	}
 	switch channel {
 	case "cli", "webui", "http":
 		return LevelInteractive