OWC v1.4.10
亮屏快充守护的稳定性修复版。四项改动，全部来自 2026-09-16 真机实测发现的问题。
核心语义不变：安全栏 = 保险丝（不到阈值不干涉，一到阈值立即熔断并完全交还系统）。
阈值全局统一，不区分游戏。
1. 复归确认「连续」→「累计/去尖刺」
问题：v1.4.8 的复归死区 + 连续 3 次确认，在真实游戏负载下从未走完过 3/3。
实测日志（异环 + 亮屏快充，2026-09-16 00:18~00:21）：
| 时刻 | CPU | 状态 |
|---|---|---|
| 00:18:22 | 83300 | 复归确认中 1/3 |
| 00:18:27 | 94200 | 熔断持续（+10900，跨回熔断线） |
| 00:19:21 | 91500 | 复归确认中 1/3 |
| 00:19:27 | 93800 | 熔断持续（+2300） |
| 00:19:39 | 91500 | 复归确认中 1/3 |
| 00:19:44 | 93800 | 熔断持续 |
| 00:20:45 | 90700 | 复归确认中 1/3 |
| 00:20:51 | 93400 | 熔断持续 |
全日志统计：1/3 出现 4 次，2/3 与 3/3 各 0 次。
根因：单次采样尖刺（±5.5°C）比确认窗口更宽，"连续 N 次"是个永远攒不满的窗口。
分子恒为 1，紧接着必被一次撞线清零。
曾评估把
RESUME_CONFIRM从 3 降到 2 —— 实测证明无效：分子只到 1，降为 2 同样攒不满。
修法：达标次数累加，尖刺不再立即清零；仅当「连续尖刺」超过容差才重置。
新增 RESUME_SPIKE_TOLERANCE=2。
熔断判定（TRIP_*）与保险丝行为零变化 —— 仅放宽"必须连续"。
2. cleanup 幂等化（根治 trap 并发重入）
问题：同一秒执行 4 次 restore。
实测日志：
00:11:18 守护进程退出，恢复所有系统状态 ×4
00:11:18 已交还 cool_down 降流控制权 ×4
00:11:38 守护进程退出 ×2 已交还 ×2
根因：trap cleanup EXIT INT TERM 三个信号指向同一函数，而函数内 exit 0
会再次触发 EXIT，叠加外部并发信号即造成重入。
修法：RESTORE_DONE 幂等标志 + mkdir 原子锁做退出互斥。
单测抓到的坑：初版在"抢锁失败"分支也置位了
RESTORE_DONE=1，会导致抢锁失败者
既不还原也不复位标志 ⇒ 锁释放后 restore 永不执行、系统状态静默卡住。
已修正为「抢锁失败不置位」，保留重试机会。
3. 来源=unknown 归因修复
问题：WARP_GUARD_SRC 只在真熔断时赋值，而守护退出 / 用户关磁贴 / 断充
都会直接调用 restore_warp_charge，此时为空 ⇒ 日志打印 来源=unknown。
修法：restore_warp_charge 接受归因参数，5 处调用点显式传入：
- 过热熔断 →
cpu/gpu/battery/shell - 守护退出 →
shutdown - 用户操作 / 断充 →
user
4. 运行位置统一 vtools/
问题：原设计把脚本拷入 tmp/ 运行，导致 tmp/ 与 vtools/ 各存一份内容相同的
warp_charge.sh，核查时无法判断"哪个在跑"，且曾造成版本号滞后。
修法：脚本在 vtools/ 原地运行，tmp/ 只放运行时产物（日志/锁/过滤名单）。
warp_charge.sh 路径逻辑本就兼容两种位置，故本次只改 service.sh / watchdog.sh
两处启动方，核心脚本零改动。
验证
- 复归状态机单测 21/21 通过（含「达标夹尖刺」—— v1.4.8 会失败的场景）
- cleanup 幂等单测 11/11 通过（含上述初版 bug 点）
- 四脚本语法检查全绿，无 CRLF
- 真机热更验收：双守护
PPID=1稳定存活，亮屏快充正常激活11984 1 sh .../OWC/vtools/warp_charge.sh 12165 1 sh .../OWC/vtools/watchdog.sh 19:29:28 亮屏快充已激活（充电接入｜游戏=0） - 归因修复当场验证生效：日志打出
来源=shutdown（旧版此处为unknown）
升级
直接刷入 OWC_v1.4.10.zip 覆盖安装即可，无需清数据。
App（控制中心磁贴）随包更新，APK 沿用旧版签名，可正常覆盖。
versionCode 18 → 19。
@author bomo
