fix: 保留系统包管理器锁状态

[eyaeya]

Dependency chain

无依赖，可独立合并。建议先于自动更新类改动合并，避免后续更新路径继续继承系统锁误删行为。

问题现象

OpenClash 在版本显示、调试信息、历史缓存判断和版本更新预检查中，会直接删除 /var/lock/opkg.lock 或 /lib/apk/db/lock。如果系统里同时有 LuCI、用户 shell 或系统 feed 操作在运行，这会绕过包管理器自身互斥，让两个包管理流程并发访问同一数据库。

根因

这些路径只是读取包版本、CPU 架构或执行 opkg update / apk update，但代码在读取前后无条件 rm -f 系统包管理器锁文件。锁文件属于 opkg/apk 的互斥状态，不应由 OpenClash 的查询脚本清理。

证据

• openclash_update.sh 原先在读取当前版本、opkg update / apk update 后、安装脚本校验版本时删除系统锁。
• openclash_version.sh、openclash_debug.sh、openclash_history_get.sh 原先在只读查询前删除系统锁。
• LuCI helper luasrc/openclash.lua 和 controller 中也存在同类只读查询前删锁。
• 新增 tests/openclash_package_lock_test.sh 对整个 luci-app-openclash 做回归扫描，防止这些路径重新引入系统锁删除。

修复方案

• 移除 OpenClash 运行时脚本和 LuCI 查询路径中的系统包管理器锁删除。
• 保留原有 opkg status、apk list/info、opkg update、apk update 调用和错误处理，不改变下载代理、重试次数或安装流程。
• 新增 focused test，要求仓库内不再出现删除 opkg/apk 系统锁的代码。

为什么没有扩大范围

本 PR 只处理“OpenClash 不应删除系统包管理器锁”这一项。后台安装期间固定包路径、OpenClash 自有 flock 锁文件删除、启动状态判断等是独立竞态问题，应单独审查和提交，避免把不同风险混成一个大改动。

与已有开启态 PR 的关系

• feat: schedule automatic version updates #5197 涉及自动版本更新入口和退出状态，但没有移除系统包管理器锁删除；本 PR 可作为其前置健壮性修复。
• feat: expose Smart sticky sessions #5198 以及 feat: add Smart sticky sessions mihomo#10 是 Smart 粘性会话相关，互不相关。
• 已合入的 fix: 校验控制面板更新结果 #5193/fix: 保留下载失败的 HTTP 状态 #5208/fix: 分离 fw4 IPv4/IPv6 DNS 劫持判断 #5209/fix: 原子替换核心文件 #5210/fix: 修复 watchdog UPNP 动态规则刷新 #5211 分别覆盖 dashboard 校验、下载失败状态、fw4 DNS guard、核心文件替换、watchdog UPNP，不覆盖本问题。

验证

• 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 写入验证；本次不触碰真实路由器配置和包数据库。

剩余风险

如果 opkg update 或 apk update 被超时强杀后包管理器自身留下不可恢复的 stale lock，需要另行做 owner-aware 的超时恢复策略；本 PR 不恢复无条件删锁行为。

[eyaeya]

这个拆分 PR 已被新的合并版 PR 取代：#5231

原因：#5217、#5218、#5222 都属于更新/版本状态健壮性修复，并且按任意顺序合并时会在 luci-app-openclash/root/usr/share/openclash/openclash_version.sh 产生真实冲突。新的合并版 PR 保留了本 PR 的行为，同时把相关冲突点一次性整理成单个 reviewer 友好的提交。

已在合并版 PR 中验证：

• focused tests
• 相关 shell bash -n
• git diff --check
• conflict marker scan
• 多轮对抗式复核，最终无修改点