插件管理器：一次未完成的热重载会永久锁死 profile（package.json 写锁不释放 + HMR 队列永挂，只能重启 DSH）

[POCO1010]

Summary

DSH Desktop 0.2.2-rc.1：在「设置 → 插件」里做一次 bundle 开关，如果随后的 hot reload 没有结束，这次操作会永久占住 profile 的 package.json 写锁，并堵死 HMR 的串行队列。此后所有插件安装/更新/卸载/开关，以及所有设置保存，都会一直转圈（约 120s 后报一次 writer lock 超时），用户没有任何办法自救，只能退出 DSH 重开。

这类挂起不会自愈，因为锁的自动回收只认“记录的 PID 已经退出”，而记录在锁里的恰恰是仍然存活的宿主进程 PID。

Reproduction

1. macOS 桌面版，profile 里装有若干（社区）bundle；
2. 「设置 → 插件」中禁用某个 bundle（本次触发者为 dshmarket）；
3. 这一步的行为：package.json 里的 dsh.profile.bundles 已经写入（目标 bundle 被移除），但 cordis.patch.yml 的 mtime 停在此前 —— 说明操作写完了清单，卡在 reload；
4. 再点任意插件的「更新」或「卸载」：UI 一直转圈，约 120 秒后报
   atomic-write: timed out waiting for the writer lock at <profile>/package.json.lock；
   此时 ~/.dsh/profiles/<profile>/package.json.lock 的内容是宿主进程 PID（现场：43091，mtime 与 package.json 同为挂起时刻，之后 45 分钟未变动）；
5. 期间 pnpm 侧完全正常 —— 挂起时刻没有任何 pnpm 子进程、没有新的 .plugin-manager/logs/operation-*，registry 也通（单次安装 1–10s，exit=0）；
6. 只有完全退出 DSH 再重开才恢复（新 PID 让 takeOverExitedLock 生效，队列也随进程清空）。

Current behavior

• 插件页操作永久「进行中」，无错误、无超时、无可重试入口；plugin-manager/operation 诊断停留在 started，不会走到 settled / unknown。
• 崩溃残留的锁把后果扩大化：后来每一次操作都要在 withFileLock 上等 lockWaitMs（默认 120000ms）才失败，看起来就像“点了没反应”。
• 即使手工删掉 package.json.lock，后续操作仍会卡在 hmr.runExclusive() 的队列里 —— 删锁不重启不足以恢复。
• 副作用：被禁用的 bundle 的入口确实被停掉了（本次表现为插件市场从 UI 消失），但整个操作永不结算，用户无法判断它到底成功没有。

Expected behavior

• 持有锁的一方也应有超时/看门狗：单次操作超过 N 秒无进展时中止它、释放锁，并把 operation 标记为 failed，让 UI 能报错并重试；
• HMR 队列里的任务永久不 settle 时，后续任务至少应该失败返回，而不是无限排队（例如给 reconcileProfile 加 deadline / AbortSignal）；
• 锁的自动回收应覆盖“记录的 PID 就是本进程但任务已不存在”的情形（至少在宿主启动时清理残留的 package.json.lock）；
• UI 对“上一个操作仍在进行”与“上一个操作已死”应给出不同反馈，不能都表现为转圈。

Code pointers

• packages/boot/plugin-manager/src/index.ts — change() 在 withFileLock(join(this.profile.dir, 'package.json'), async () => { ... await operation(result) ... }, { waitMs: this.lockWaitMs }) 内完成整个安装/更新/卸载/开关；锁只在 operation settle 后由 finally 释放，持有者没有任何超时。
• packages/boot/hmr/src/index.ts — runExclusive() 中 this.operations = task.catch(() => {})：一旦某个 task 永不 settle，后续所有调用都排在它后面（config-editor 的保存、plugin-manager 的 configure() 都走这条链）。
• packages/util/atomic-write/src/index.ts — holderExited()（if (pid === process.pid) return false）与 takeOverExitedLock() 只处理“PID 已不存在”的残留锁，注释中也写明：“A holder whose PID a live process reused keeps its lock until an operator removes it.” 这条保守策略正是本次无法自愈的原因：PID 没有复用，它一直活着，只是它的任务卡死了。
• 相关配置：lockWaitMs 默认 120000（packages/boot/plugin-manager/src/index.ts 的 Config）。

Environment

• DSH Desktop 0.2.2-rc.1（macOS 26.5.1 / arm64，App 内 dsh 0.2.2-rc.1）
• 内置 pnpm 11.28.5，node v26.3.1
• profile：~/.dsh/profiles/desktop（nodeLinker: hoisted，7 个依赖 / 8 个 bundle 层，含社区 bundle）
• 现场证据（如需要可补）：package.json.lock = 宿主 PID、mtime 15:10；package.json mtime 15:10 而 cordis.patch.yml mtime 15:03；.plugin-manager/logs/*/pnpm.log 最后一条 15:09:27 成功、.dsh-market/log.ndjson 同日 15:09 收尾；挂起后 45 分钟无子进程、无新增连接。

Severity

阻断级但静默：用户能看到的现象只有「转圈」，既没有错误也没有日志入口；由于 profile 写锁是全局的，一个卡死的操作会连带禁用整个插件管理能力（以及设置保存），只能重启进程。