fix: 隔离每轮更新安装包路径

[eyaeya]

Dependency chain

无硬依赖，可独立合并。若与 #5217/#5218 同批处理，建议先合并 #5217 和 #5218，再合并本 PR，便于先稳定锁语义再处理后台安装交接竞态。若 #5197 后续继续修改 openclash_update.sh，需要保留本 PR 的 per-run package/helper staging 语义。

问题现象

OpenClash 更新父脚本在预检后启动后台安装脚本，但父脚本结束后会释放外层更新锁。后台安装脚本原先读取固定的 /tmp/openclash.ipk 或 /tmp/openclash.apk，且 helper 脚本也固定为 /tmp/openclash_update.sh。此时第二次更新可以进入父脚本，删除或重写第一轮仍在使用的交接文件。

根因

下载和安装跨越两个进程：父脚本负责下载和启动 procd 后台服务，后台脚本负责实际 opkg install / apk add。两者通过固定 /tmp/openclash.ipk|apk 和固定 /tmp/openclash_update.sh 交接状态，但这些路径不随启动轮次隔离。

证据

• 父脚本原先每轮下载到固定 /tmp/openclash.ipk|apk。
• 后台安装脚本原先直接安装同一固定包路径。
• 后台 helper 原先固定为 /tmp/openclash_update.sh，第一轮延迟清理可能删除第二轮刚生成的 helper。
• 新增 tests/openclash_update_package_path_test.sh 禁止固定包路径和固定 helper 路径回归，并要求后台安装脚本接收本轮 staged package 路径。

修复方案

• 父脚本下载到 /tmp/openclash_update_$$.ipk|apk，每轮进程独立。
• helper 脚本生成到 /tmp/openclash_update_$$.sh，ubus command 和延迟清理都使用该路径。
• 生成后台安装脚本时注入本轮 staged package 路径，并让 opkg install / apk add 读取该路径。
• 如果第二轮后台安装因安装锁已存在而退出，只清理第二轮自己的 staged package，不影响第一轮。
• 安装成功后清理本轮 staged package；安装失败时保留路径并在日志里提示手动安装命令。

为什么没有扩大范围

本 PR 不改变下载 URL、代理、重试、安装锁、包管理器调用参数或自动更新返回语义。系统包管理器锁删除由 #5217 处理；OpenClash 自有 flock 锁文件稳定性由 #5218 处理。

与已有开启态 PR 的关系

• feat: schedule automatic version updates #5197 增加自动更新入口，可能提高触发这个竞态的概率，但没有把后台安装交接文件变为每轮唯一；本 PR 补足这一点。
• feat: expose Smart sticky sessions #5198 和 feat: add Smart sticky sessions mihomo#10 是 Smart 粘性会话相关，互不相关。
• 已合入的 fix: 保留下载失败的 HTTP 状态 #5208/fix: 原子替换核心文件 #5210 不覆盖后台安装期间固定交接路径被覆盖的问题。

验证

• bash -n luci-app-openclash/root/usr/share/openclash/*.sh：通过
• bash -n luci-app-openclash/root/etc/init.d/openclash：通过
• bash -n tests/*.sh：通过
• for t in tests/*.sh; do bash "$t"; done：全部通过
• git diff --check：通过
• rg -n '^(<<<<<<<|=======|>>>>>>>)'：无匹配

未做 live router 写入验证。

剩余风险

如果后台安装已经进入包管理器内部，仍依赖系统包管理器自身的锁和错误处理；本 PR 只保证 OpenClash 不再通过固定 /tmp/openclash.ipk|apk 或固定 /tmp/openclash_update.sh 跨轮覆盖安装输入。