PR #4384 需要维护者确认：插件基座与核心鉴权路径

[MagicLizi]

PR https://github.com/makecindy/cindy/pull/4384（head ecb426fe3138b0938c2e9324bc0a5853e68fbeb4）触发维护者确认门，当前 blocker 为 pluginBase，同时命中 arch。

这次改动

运行时 refresh 得到确定性凭证失效后，把 expiry 绑定到发起时的 auth epoch / realm / owner，避免等待 vault 删除期间的迟到 expiry 清掉新会话或新凭证。主要改动在 Desktop 主进程鉴权：

• apps/desktop/src/main/authManager.ts
• 新增 apps/desktop/src/main/authRuntimeExpiryGuard.ts
• apps/desktop/src/main/bootstrap-electron.ts（抽出 owner post-commit 任务，并增加 session restore）
• apps/desktop/src/main/localDb/ipc/registerAll.ts（导出 ensureRegisteredLocalDbOwnerReady）
• 对应鉴权单测

为何需要确认

1. pluginBase（当前 blocker，无 bugfix 豁免）：改到 apps/desktop/src/main/plugin-market/__tests__/ipcErrorBoundary.test.ts。该文件落在插件基座路径上，规则要求维护者对存量插件兼容明确确认。从 diff 看，这里只是跟随 bootstrap 函数抽取，更新了源码字符串锚点，不是插件运行时/沙箱/批准状态本身的行为改动；但仍属基座路径命中，不能由审查流程自行放行。
2. arch：核心路径改动 1008 行（≥150），且总 diff 1008 行（≥800）。覆盖鉴权主路径、bootstrap 与 localDb IPC 注册。

作者 Dante-dan 不是维护者，当前 head 也没有维护者的有效 Approve。

请维护者

请直接在 PR 上 Approve 放行讨论门；如果需要作者修改，请 Request Changes。普通评论、讨论 issue 留言或手工摘标签都不构成通过。

---

关联 PR:#4384(作者 @Dante-dan);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的插件基座改动(影响全部已装插件),维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：PR #4384 具备明确的用户价值，目标是修复 Desktop 主进程中“确定性 refresh 失败的清理动作晚于并发重登/切号完成”这一竞态，防止旧 expiry 清除新会话或新凭证。该方向值得推进，但当前版本应先完成审查发现的状态一致性与测试缺口，再由维护者在 PR 上作出明确的 Approve 或 Request Changes；本 Issue 本身是评审门禁，不是新的用户故障报告。\n\n## 已确认的范围\n\nPR #4384（当前 head ecb426fe3138b0938c2e9324bc0a5853e68fbeb4）修改 8 个文件，936 行新增、72 行删除，涉及：\n\n- apps/desktop/src/main/authManager.ts：运行时确定性失效清理、owner teardown 与凭证处理；\n- apps/desktop/src/main/authRuntimeExpiryGuard.ts：抽取 auth epoch / realm / owner 代次保护；\n- apps/desktop/src/main/bootstrap-electron.ts：owner post-commit 任务及 session restore；\n- apps/desktop/src/main/localDb/ipc/registerAll.ts：本地数据库 owner readiness 注册；\n- apps/desktop/src/main/plugin-market/__tests__/ipcErrorBoundary.test.ts：随 bootstrap 函数抽取更新源码字符串锚点。\n\nPR 自报的定向测试为 2 个文件、38 个测试通过，TypeScript、DCO 和 diff 检查通过。其设计保持瞬态失败、DEVICE_MISMATCH 与凭证读取失败的既有保留策略，仅对服务端明确拒绝的 refresh generation 做定向清理。\n\nIssue 所述 pluginBase 门禁事实成立：虽然当前插件路径变更看起来是测试锚点调整，并未显示插件运行时、沙箱、批准状态、指纹、manifest 或安装布局行为变化，但该路径仍命中仓库的维护者确认规则，不能由自动流程自行豁免。与此同时，改动规模和核心鉴权/bootstrap/localDb 覆盖范围构成 arch 门禁。作者不是维护者，当前 head 也没有有效维护者 Approve，因此 PR 暂不能依靠普通评论或手工标签继续推进。\n\n## 需要先解决的技术问题\n\nPR 讨论中的 Greptile 审查提出了三项具体风险，其中前两项直接涉及用户可见的状态可靠性：\n\n1. 持久化 signed-out 失败时的兜底可能被跳过。 当前 expiry 流程先执行清态并递增 authStateEpoch，再提交 signed-out session。如果持久化因权限或 I/O 失败，guard 可能把“本次 expiry 自己造成的 epoch 变化”误判为已被新 auth action 取代，进而跳过 commitVolatileAppSession('signed-out') 和最终通知。建议区分 expiry 自身的清态与真正的新登录/切号取代，并增加持久化失败回归测试。\n\n2. passive 实例的本地登出墓碑可能丢失。 为保留共享持久凭证，确定性 expiry 走了 preservePersistedRefreshToken 路径，但该路径可能不再设置 passiveLocalSignOut。若 primary 随后写入有效凭证，passive 实例重新初始化时可能重新采用 primary 会话。建议只在当前 expiry generation 确实提交时设置 passive 墓碑，同时保留共享凭证，并确保陈旧 expiry 不得设置新会话的墓碑。\n\n3. 测试尚未覆盖真实 vault CAS 行为。 现有 guard 测试让删除回调直接返回 stale，而不是在等待期间实际写入替换 generation；源码结构断言也不能证明 compare-and-delete 没有误删。应增加行为测试：在 vault 锁等待期间写入替换 token，确认新 token 和兼容记录保留；对未被替换且确实被服务端拒绝的 generation，确认其被删除。\n\n上述问题来自 PR 的公开审查讨论，尚未看到作者已修复或新的验证结果，因此不建议仅凭当前测试报告放行。\n\n## 与既有问题的关系\n\n- #4381：报告 macOS 长时间休眠后需要重新登录。#4384 明确将其作为相关背景，但也明确不宣称解决所有休眠后登出场景；该 Issue 的现象仍需按网络恢复、access token 是否为空、safeStorage、服务端确定性失效和 Renderer 状态广播分别验证。\n- #3505：已合并的多账号能力引入 Desktop safeStorage refresh-token vault 和账号边界。它是本 PR 需要保护的现有会话恢复/切号基础，但不是本次竞态的直接故障证据。\n\n进一步检查历史讨论可知，v0.1.79 已包含 Electron powerMonitor resume 接线、authManager.handleResume() 以及瞬态/确定性 refresh 失败分类，因此不能把 #4381 简化为“发布版本缺少恢复代码”，也不能据此提出无条件保留失效 token。\n\n## 建议行动与验收\n\n1. 作者在 #4384 更新实现：区分 expiry 自身 epoch 变化与外部新 auth action，确保持久化失败仍有 volatile signed-out 兜底和最终通知；恢复 passive 实例墓碑语义，并补充对应回归测试。\n2. 增加真实 vault compare-and-delete 行为测试，覆盖并发替换 generation、不同 realm/owner、失败清理及重复 expiry。\n3. 维护者复核完整 diff，尤其是 authManager.ts、authRuntimeExpiryGuard.ts、bootstrap/localDb IPC 抽取，以及 plugin-market/__tests__/ipcErrorBoundary.test.ts 的兼容性影响。确认插件基座仅为测试锚点变化后，仍需按规则在 PR 上明确 Approve；若技术问题未解决则 Request Changes。\n4. 合并前验证：确定性 invalid token、瞬态 429/5xx、safeStorage/I/O 持久化失败、并发重登/切号、passive/primary 多实例、唤醒后 access token 为空但 refresh token 仍在，以及 Renderer 状态广播时序。\n\n当前可执行结论：保留并推进 #4384 的修复方向，但先 Request Changes 修复上述缺口；完成修复和行为测试后，再由维护者在 PR #4384 上 Approve 解除讨论门禁。