merge: pr31 — update 回滚安全（原子写 + 回读校验），解 19 处冲突

pr31 与 main 是**双向分叉**，不是单向落后。`ba281a8` 已把它的多数工作
在 main 上重新实现（dataDir 守卫、gc.go、dataDir 解析），但两边各自又
往前走了，所以 6 个文件 19 处冲突要逐条判。

## 合进来的（main 缺）

- **标记原子写**：main 是 `os.WriteFile` 直接覆写，掉电留半截标记；
  改为 `写 .tmp → fsync → close → rename → fsync 目录`
- **H4**：`publishResult` 里 `if errMsg != "" { _ = errMsg }` 把失败原因
  丢了，订阅方只看到 ok=false。现在 error 字段恒定存在
- **回读校验补最低可用性**：main 对无 digest 的旧 marker 只比"内容与备份
  一致"，而**零字节备份内容也一致** ⇒ 判成回滚成功、不清 marker 的时机
  也错过了。补"非空 + 带可执行位"，刻意**不**要求 `--version`
  （老内核没这个 flag，那正是 PR #31 的回归）
- `kernel_apply_test.go`（836 行，含 B2c `TestMarkPendingUpgrade_PreservesOldMarkerOnFailure`）

## 保留 main 的（pr31 在这几处是旧版或更差）

- **回滚校验用 digest**（`verifyRestored`）而不是 `--version`：
  pr31 要求回滚后能读版本，而 1.3.x 及以前没有 `--version`，
  而它们恰恰是最常见的回滚目标 ⇒ 从旧版升级失败后永久回滚不了
- **`restoreDepGraph` 三态**：原来有+备份有→还原、原来有+备份无→不算成功、
  原来无→删掉新装的。pr31 只处理第一种，会导致「旧 homed + 新 depgraph」
  的崩溃循环
- **marker 在还原完整后才清**：pr31 在还原前就清，还原失败即失去第二次自愈
- **CLI 不重启服务**：pr31 仍带 `restartUnit`，会杀掉整个 cgroup 连带 guard
- **`resolveDataDir`**：pr31 的 `upgradeDataDir` 是它的子集，多扫几个候选前缀

## 冲突处理中的三处重复声明

两边各加了同名函数，自动合并把它们都留下了：

- `readBinVersionStrict` —— 删 pr31 的（main 在 77 行有）
- `kernelDataDirMu/kernelDataDir/SetKernelDataDir/KernelDataDir` —— 删 kernel.go
  里那份（main 在 install.go）
- `newPkgRoot` —— pr31 的重命名 `newPkgRootFromBin`，两套测试各自可用
- rollback.go 里 `verifyRestored` 与 `readBinVersionStrict` 两段校验并存 —— 删后者

顺带修掉删除时误伤的 `ShortSum` 注释，并删掉 pr31 引入但无人调用的
`DataDirEnv`（main 明确不再拿 env 当 dataDir 来源）。

## 验证

    go build ./...                        ✓
    go vet ./...                          ✓
    go test ./... -count=1                62 ok / 0 fail
    go test -race ./internal/update/ ...  ✓
    gofmt -l                              干净

internal/plugins/webui/kernel_update.go

@@ -163,16 +163,15 @@ func currentKernelVersion() *update.BinVersion {
 	return v
 }
 
-// dataDirOf 返回内核**真实**的数据目录（升级确认标记的落点）。
+// dataDirOf 返回内核**真实**的数据目录（ks.DataDir，来自 `-data`）。
 //
-// ★ 取内核注入值（ks.DataDir），不做任何推导：pending 标记落在哪，
-// 第 0 层 update 模块就从哪读；两边一漂移，升级失败时就**静默不回滚**。
-// 而“猜一个看起来合理的路径”会让 Apply 的空值守卫变成死代码。
+// ★ 取注入值，不做任何推导：pending 标记落在哪，第 0 层 update 模块就从
+// 哪读；两边一漂移，升级失败时就**静默不回滚**。而“猜一个看起来合理的
+// 路径”（曾用过 env → exe 同级 data）会让 Apply 的空值守卫变成死代码——
+// 实测生产是 `--data /var/lib/hologram`，而 exe 推导得 /usr/bin/data
+// （只读目录，建备份必 EROFS）。
 //
 // 拿不到就返回空串，由 Apply 拒绝升级并报错。
-//
-// ⚠️ 不要再加 HOMEAGENT_DATA_DIR 回退：部署方可能不设，而设了也未必
-// 与内核实际的 -data 一致 —— 那正是“看起来在工作”的一类错误。
 func dataDirOf(binPath string) string {
 	return update.KernelDataDir()
 }