feat(webui+guard): 内核重启/关机按钮，指令走心跳复用既有协议

## 需求

WebUI 加关机与重启按钮，内核提供对应内部接口。有些状态变更只能靠重启
生效（换 LLM 源、换主密钥），没有这条通道时用户只能 ssh 上去敲 systemctl。

## 设计：复用心跳，不新开通道（用户指出的方向）

guard 与 worker 之间已经有一条现成的、每 5s 一次的单向通报（心跳文件，
内容原本是 `t=<unix>`，只用来刷 mtime）。用户点按钮本质就是"我要你在
下一次心跳时知道这件事"——再开 unix socket / 信号 / 临时文件，只会多出
一套要防重、防丢、防竞态的机制。

    WebUI 点按钮
      → POST /api/v1/kernel/{restart,shutdown}
      → sdk.KernelControlAPI（只投递，立即返回）
      → 下一次心跳把 `cmd=restart|shutdown reason=...` 写进 <data>/heartbeat
      → 重启：worker 清理 → exit 42 → guard 重拉（**既有机制，零改动**）
        关机：guard 在 workerCleanExit 分支读到 cmd=shutdown
              → systemctl stop → 不再拉起

★ 关机为什么必须由 guard 做：
  unit 是 Restart=always，guard 自己 return 会被 systemd 立刻拉起
  （用户点了"关机"、几秒后服务又活了）。必须显式 systemctl stop。
  而不让 worker 自己停：它是被守护方，且**只有 guard 知道这次该不该重拉**。

★ 指令必须一次性消费：guard 读完立即原子重写文件清除 cmd 行，
  否则每次心跳都读到同一条 ⇒ 无限重启/关机。worker 侧还要检查
  "指令写过但文件里没了" ⇒ 已被消费 ⇒ 清本地 pending，否则又写回去。

## 顺带修的真缺陷：心跳文件无限增长

生产实测 **14.6MB**（纯 O_APPEND，约 70 天）。心跳的唯一职责是刷 mtime，
历史行没有任何读者 ⇒ 每次 consume 要整读 14.6MB（实测 27ms）。
改为 O_TRUNC 滚动写：只保留当前一行。真机验证 15,322,164 → 13 字节。
consume 也加了尺寸守卫（大文件只读尾部 8KB）。

## 安全：能力分级 + 白名单（两道）

1. proc 桥的 method 能力表：新增 `CapKernelControl` 一档。
   ★ 判据 `TestCapability_AllMethodsClassified` 当场报出
   "未登记 ⇒ 会按 CapCore 放行，绕过权限检查" —— 那意味着任何插件都能关机。
2. 内置插件走 `SDKConfig.KernelControl`，第一版我写成"有就发"，
   等于全部内置插件都能关机。改为按名字白名单（目前只有 webui）。

## 判据（7 条）

心跳：解析 / 消费后必须清除 / worker 不得写回已消费指令 / 未消费时必须续写
能力：只有白名单插件拿得到 / 未装配时返回 nil 不 panic / SDK nil 安全
心跳文件：不得无限增长 / 大文件只读尾部且读后收敛

变异 6/6 咬住。全量 53 包 ok。

## UI

导航底栏两个图标按钮（与主题/语言/退出并列）：重启有确认框 + 轮询等它
回来并自动刷新；关机有**二次确认且写清后果**（必须人工 systemctl start）。
两者都先把响应写回浏览器并 Flush，再让内核退出 —— 否则用户看到的是
connection reset，无法区分"正在重启"和"真出故障了"。

internal/plugin/proc/capability.go

@@ -63,6 +63,20 @@ const (
 	// 这是**最敏感**的一组：能重载其他插件意味着能间接影响它们的状态。
 	CapPluginMgr Capability = "plugin_mgr"
 
+	// CapKernelControl 控制**内核本身**的生死（重启/关机）。
+	//
+	// 这是整个能力表里**最危险**的一档：它不改变某个插件的状态、
+	// 也不改配置，而是让**整个服务**停下来。
+	//
+	// 与 CapPluginMgr 的区别（别混）：
+	//   CapPluginMgr     能重载**别的插件** —— 影响一个插件
+	//   CapKernelControl 能重启/关机**内核** —— 影响全部插件 + 全部用户
+	//
+	// 关机之后服务不会自己回来（systemd Restart=always 由 guard 显式
+	// systemctl stop 压制），必须人工介入。因此默认**不授予**任何插件，
+	// 必须由 manifest 显式声明。
+	CapKernelControl Capability = "kernel_control"
+
 	// CapCrossPluginSettings 读写**其他插件**的配置与内核核心配置。
 	//
 	// 与 CapCore 里的「读写自己的配置」区分开：跨插件配置读写能改别人的行为，
@@ -160,11 +174,14 @@ var methodCapability = map[string]Capability{
 	MethodEventsUnsubscribe: CapEvents,
 
 	// ---- 插件管理 ----
-	MethodPluginReloadOne:           CapPluginMgr,
-	MethodPluginListLoaded:          CapPluginMgr,
-	MethodPluginIsDisabled:          CapPluginMgr,
-	MethodPluginMgrStop:             CapPluginMgr,
-	MethodPluginMgrStart:            CapPluginMgr,
+	MethodPluginReloadOne:  CapPluginMgr,
+	MethodPluginListLoaded: CapPluginMgr,
+	MethodPluginIsDisabled: CapPluginMgr,
+	MethodPluginMgrStop:    CapPluginMgr,
+	MethodPluginMgrStart:   CapPluginMgr,
+	// 内核生命周期控制：单独一档，见 CapKernelControl 的注释。
+	MethodKernelRestart:             CapKernelControl,
+	MethodKernelShutdown:            CapKernelControl,
 	MethodPluginMgrIsRuntimeStopped: CapPluginMgr,
 
 	// ---- 跨插件 / 核心配置 ----