feat(session): occupancy 写入 SQLite，所有权不再读心跳文件

[LucasIcarus]

Summary

• 以 origin/master@82054f7b（已含 refactor(session): 删除 daemon 侧 JSON 写路径，落盘改为行级 upsert #1051）为基线，落地 Session 终态 Stage 1：per-bot sessions.db 新增 occupancy 表（scope / owner_pid / boot_id / lease_until）。daemon 在首次 load() 的 BEGIN IMMEDIATE 里写入租约，30s 续期，shutdown / exit 按 boot_id 释放。
• SQLite 离线写在同一事务内读租约：有效则中止，过期则允许现有离线 apply（不在本进程抢租约）。findOnlineDaemon 不再作为默认所有权，只保留 IPC 发现与 dashboard 展示。
• 租约行不存在时回落心跳，兼容尚未重启的 refactor(session): 删除 daemon 侧 JSON 写路径，落盘改为行级 upsert #1051 daemon；JSON 升级窗口路径仍走 abortIf。删除该回落的条件与 Stage 0 JSON 读路径相同。本 PR 不做 Stage 2（单一 apply）也不删 JSON 读路径。

影响面

• 共用路径：session-store、session-offline-write、daemon 启停心跳、CLI close / abandon / prune、whiteboard 离线解绑。
• 会话类型：话题 / 群 / adopt / restore 走同一套 store 导出；Pty / Tmux、sandbox on/off 不另开所有权协议。
• 不改 <dataDir>/heartbeats/ busy-count，不把旁路文件并进会话库。

Test plan

• tsc --noEmit 干净
• bun run build 通过
• bunx vitest run test/session-occupancy.test.ts test/session-store-sqlite.test.ts test/session-store.test.ts test/whiteboard-unbind-session.test.ts test/session-delete-cli.test.ts test/daemon-discovery.test.ts（157 条通过）
• CI 全绿
• 合入后观察：新 daemon 重启后库内出现 occupancy 行；旧 daemon 未重启时 close / abandon 仍走缺行回落；租约过期后即使心跳文件仍在，离线写应能落盘

Made with Cursor

[deepcoldy]

感谢这个 PR —— 把所有权从旁路心跳文件搬进会话库的同一个 BEGIN IMMEDIATE，是对「探测与写入之间那道缝」的正解。以下是自动评审的初步意见，最终以维护者审阅为准。

结论：0 阻断，1 条非阻断建议

已同步到最新 origin/master（ba9bc72ae）rebase 验证：0 冲突（仅 src/cli.ts 因 #1220 产生 1 行偏移）。tsc --noEmit 干净、build 通过、相关 267 条测试全绿（在 rebase 后的树上重跑，因为 CI 的绿是在旧 base 上跑的）。新增的 test/session-occupancy.test.ts 17 个用例全部真实执行。

我们对几处承重逻辑做了变异测试，确认断言都有牙：把「租约有效」改成恒假、摘掉进程存活检查、把「抢占仍存活的前任租约」这个危险方向放开、砍掉心跳回落腿、把 CLI 侧退回改动前的行为 —— 五种变异全部触发红灯。有条件接管（前任还活着就不抢、只记 warn 并在心跳里重试）和关停期「租约持有到最后一刻」这两个设计尤其稳妥。

🟠 非阻断建议：mutateSessionRowOffline 的锁竞争建议收敛成 undefined

openDbForOwnStore 在 try 块之外，所以拿不到写锁时异常会直接穿出 mutateSessionRowOffline，而不是像「租约被持有」那样干净地返回 undefined。

这一点需要说清楚归因：我们最初怀疑是新增的 CREATE TABLE IF NOT EXISTS occupancy 引入的，于是把「DDL 只在 owning daemon 的 load() 里做」这个修法实现出来实测 —— 窗口并没有消失，抛出点只是从 DDL 挪到了 mutateSessionRowOffline 自己的 BEGIN IMMEDIATE。随后把 session-store.ts 换成 origin/master 版本跑同一个探针，得到逐字相同的 database is locked。

所以这是既有行为，不是本 PR 引入的缺陷。 建议之所以仍然提出来，是因为本 PR 会在部署当刻短暂抬高它的触发概率（见下）。

建议的小改（可选）：把 openDbForOwnStore 挪进 try，把锁竞争映射成 undefined —— 与「租约被持有」同语义的干净放弃，CLI 侧不再抛栈。我们不建议改成「offline writer 不建表」，实测那样只是把抛出点挪位，却多引入一个开关和「谁能建表」的分叉。

📌 部署期的一个预期现象（供值班同学心里有数，不是缺陷）

线上实测：57 个 store 目前都还没有 occupancy 表。也就是说部署那一刻，每个 bot 首次打开自己的库时都要真正执行一次建表写入。CREATE TABLE IF NOT EXISTS 在表已存在时是纯 no-op（实测 1ms、不取锁），但首次是真写：若恰好撞上一个持有写锁超过 busy_timeout(3s) 的写者，daemon 侧会重启一次（自愈 —— 表由第一个成功者建好，重试即 no-op），CLI 侧会报一次 database is locked。

概率很低（本库没有长写事务、WAL 下读不阻塞写），且如上所述这个错误形态在改动前同样存在 —— 只是部署当刻是 fleet 范围同时经历一次，值得提前知晓。

其他几点（均无问题，仅作确认）

• removeDaemonDescriptor 增加 bootInstanceId 归属校验是正确的修复：重启重叠期旧 daemon 不会再删掉后任刚发布的 descriptor。
• 「daemon 应答即权威」的语义调整经核查是安全的：唯一能放行离线写的状态是 daemon 已死超过 90s；daemon 活着但 IPC 不可达时租约或心跳必然新鲜，仍然 fail-closed。
• 被 displaced 的 daemon 不会自我降级 —— 实测其读写照常，租约只用于阻挡其它进程的离线写。
• 心跳回落确实必要：线上 57 个 SQLite store 与 57 份冻结 JSON（56 个 per-bot + 1 个 legacy）并存，其中 10 个 bot 尚未跑过 Stage-0 导入，两条兼容路径都在承重。设计文档把删除条件挂在「fleet 自动重启落地 / 2026-11-26 复核」是保守且正确的。

一点供参考：daemon 侧的 claim / release / 心跳续期 / descriptor 归属校验目前没有单测覆盖，测试集中在 store 与 CLI 层。考虑到 daemon.ts 的体量这可以理解，只是这部分需要合入后靠线上观察。

以上是自动评审的初步意见，最终以维护者审阅为准。