fix(update): 重启交还 guard、OTA 支持 release/包两种来源、修三处真 bug

## 一、重启不再由 update 自己 systemctl（用户口径：应该通知 guard）

原 internal/update 直接 `systemctl restart homeagent`。三个问题：

① 杀掉整个 cgroup（unit 里 KillMode=control-group）⇒ **guard 跟着死**，
   而 guard 存在的意义就是不让自己死。
② 丢失 exit 42 语义：guard 的 failures/failbackRound/failbackDone 全丢。
③ 自毁竞态：发命令的进程正是被重启杀掉的进程 ⇒ CombinedOutput 可能报错，
   **一次成功的升级被误判失败而回滚**。

现在 internal/update 只到"产物就绪"：预检 → 备份 → 写 pending → 原子替换。
重启由调用方走**既有**通道（restartCh → exit 42 → guard 用新二进制重拉）：

· webui      h.kernelCtl.RequestKernelRestart（本来就有，且是白名单内）
· pluginmgr  p.sdk.KernelControl().RequestKernelRestart（见下面第三条）
· CLI        外部管理命令，restart unit 后按**版本自报**核对是否真生效

## 二、OTA 支持两种来源（release 自动更新 / 指定安装包）

新增 internal/update/source.go：

	Source{Kind: FromPackage, Path}  → 直接用本地包
	Source{Kind: FromRelease}        → 查最新 Release → 下载 → 校验 digest

ParseSource(pkg, release) 统一判空规则（pkg 优先），避免三端各写一套。
两条来源解析后进**同一条** Apply，不存在两份升级实现。

## 三、修三处已提交代码里的真 bug

① **HEAD 编译不过**：d17e261 提交了 kernelmod/update/mod.go（引用 ks.Update），
   但 kernelboot/kernelstate.go 的字段改动从未提交。干净 worktree 实测
   `ks.Update undefined` —— 推上去的仓库是坏的。本次补上。

② **kernelDataDir 算错一级**：Dir(Dir("/home/newqqagent/plugins")) = "/home"，
   而第 0 层 update 模块从 ks.DataDir=/home/newqqagent 读 pending
   ⇒ **agent 发起的升级一旦启动失败就永不回滚**（静默失效）。改为 Dir 一次。

③ **pluginmgr 的 KernelControl 恒为 nil**：它不在 kernelControlAllowed 里，
   于是 `if kc := p.sdk.KernelControl(); kc != nil` 永不成立 ⇒
   换完二进制**从不重启** ⇒ pending 留着 ⇒ 下次重启被判"未确认"而回滚。

   修法**不是**把 pluginmgr 加进完整白名单 —— 那等于让 LLM 能关机整个服务
   （kernel_control_gate_test 明确拦这个）。而是拆出**仅重启**授权：

	kernelControlAllowed  = {webui}       完整（含关机）
	kernelRestartAllowed  = {pluginmgr}   仅重启（shutdown 直接报错）

   两者的危险程度差一个量级：重启几秒后 guard 自己拉回来，关机不会自己回来。

## 四、EventBus：插件请求更新不必 import internal/update

新增 events.EventUpdateRequest，pluginmgr 订阅并受理：
scope=kernel → kernelUpdateApply；scope=plugin → pluginUpdate(apply)。

它在 internal/plugins/webui 的 SSE 守卫里显式登记为**内核内部控制事件**
（不该推给浏览器：前端要的是 update_progress/update_result，不是"谁发了请求"）。

## 五、顺手修掉的静默失败

· webui /kernel/update 原实现：**先**写 202 Accepted，**再**解析 body，
  之后每个错误都直接 `return` —— 用户看到"已受理"然后什么都没发生。
  改为同步 Apply（失败可如实报 HTTP 状态），成功后才请求重启。
· pluginmgr 拿不到控制通道时不再假装成功，而是回报 applied=true + 明确原因
  （否则用户以为已升级，进程却还在跑旧镜像）。
· update 事件 publishResult 的 errMsg 原先是死代码（`_ = errMsg`），
  按 payload 约定写回 error 字段。

internal/plugin/registry.go

@@ -293,6 +293,36 @@ var kernelControlAllowed = map[string]bool{
 	"webui": true,
 }
 
+// kernelRestartAllowed 是**仅重启**授权（不含关机）。
+//
+// ## 为什么必须把这两件事分开
+//
+// 完整通道的两个动作危险程度差一个量级：
+//
+//	RequestKernelRestart   guard 用磁盘上的二进制重拉 ⇒ 几秒后自己回来，**可恢复**
+//	RequestKernelShutdown  压制 Restart=always ⇒ 服务停住，**不会自己回来**
+//
+// 而 kernel_update 的收尾只需要"重拉"：新二进制已经换好了，不重启等于升级
+// 永远不生效 —— 更糟的是 pending 标记会在下次启动时被判"未确认"并**回滚**。
+//
+// ⇒ 给 pluginmgr 一个**去掉关机**的通道。攻击面因此限于"能让服务重启"，
+//
+//	而不是"能让服务消失"。
+var kernelRestartAllowed = map[string]bool{
+	"pluginmgr": true,
+}
+
+// restartOnly 是去掉关机能力的控制通道包装。
+type restartOnly struct{ full sdk.KernelControlAPI }
+
+func (r restartOnly) RequestKernelRestart(reason string) error {
+	return r.full.RequestKernelRestart(reason)
+}
+
+func (r restartOnly) RequestKernelShutdown(reason string) error {
+	return fmt.Errorf("该插件只被授予\"重启\"能力，未被授予关机能力（kernelRestartAllowed）")
+}
+
 // SetKernelControl 注入内核重启/关机通道（由 cmd/homed 装配时调用）。
 //
 // ★ 为何用 setter 而不是构造参数：internal/plugin 不能 import cmd/homed
@@ -320,10 +350,16 @@ func (r *Registry) kernelControlFor(name string) sdk.KernelControlAPI {
 // 拆出来的原因：buildSDK 要在**一次** RLock 里取走整组依赖（见 snapshotDeps），
 // 不能再回头单独取锁 —— RWMutex 不可重入，持锁再 RLock 在写者排队时会自锁。
 func kernelControlForCtl(ctl sdk.KernelControlAPI, name string) sdk.KernelControlAPI {
-	if ctl == nil || !kernelControlAllowed[name] {
+	if ctl == nil {
 		return nil
 	}
-	return ctl
+	if kernelControlAllowed[name] {
+		return ctl
+	}
+	if kernelRestartAllowed[name] {
+		return restartOnly{full: ctl}
+	}
+	return nil
 }
 
 func (r *Registry) SetToolRegistrar(fn sdk.ToolRegistrar) {