refactor(session): 删除 daemon 侧 JSON 写路径，落盘改为行级 upsert

[LucasIcarus]

定位

会话架构 Stage 0（口径：docs/design/2026-08-12-session-restage-store-first.md）：daemon 只写 SQLite，会话行改为行级 upsert。

不是全仓 db-only，也不是 occupancy / 单一 apply。跨进程在「CLI 已升级、daemon 尚未重启」的窗口内仍走 db-else-json；删除这条回落的条件写在设计文档 Stage 0，不在本 PR。

#852 把引擎换成 SQLite 之后，daemon 仍保留着整套 JSON 写路径（save() 整图序列化、JSON CAS、tmp+rename），session-store.ts 从约 1390 行涨到 2154 行。本 PR 删掉 daemon 侧这套 JSON 写实现：2154 → 1925。跨进程 JSON 读与离线写刻意保留（约 25 行），否则升级窗口内 botmux send 读不到会话。

本 PR 不依赖灰度已关闭：升级窗口内六项行为与 master 逐项一致（对照表见「升级窗口」）。

---

改了什么

1. daemon 不再写 JSON

删除：

• save()：整份 map 序列化 + tmp+rename + byte-identical 跳写
• load() 里的 JSON 写回，以及 legacy → per-bot 的迁移写
• readExistingSessionsFromDisk / readSessionsProjectionStrict
• Remote lineage CAS + readback 的 JSON 实现
• repairMissingChatScopes 及它每次 load 触发的写回事务
• persistRow 回落到 save() 的分支

store 内的 withFileLockSync 只剩导入一处。导入经固定的 <db>.tmp 暂存：同一 bot 的两个 owner 进程短暂并存时（重启撞上尚未回收的前任），两边都会通过 existsSync(db) 并写同一个 tmp。换成 per-process 的 tmp 名会留下无人清理的孤儿文件；直接建进最终 .db 会打破「.db 存在 ≡ 导入已完成」这条不变量。

sessions-*.json 降为一次性导入源：拥有该 bot 的 daemon 导入之后不再写它。其它进程在该 daemon 尚未导入时仍可读、可离线写，且任何路径都不得创建空 .db——空库会让导入门误判为已完成。

2. 导入期做一次性归一化，且不按 sessionId 重键

stripLegacyPendingCardFields / repairMissingChatScope 只在导入时执行一次。loadAllSessionsSnapshot 仍做纯内存归一化（它读的是别人的 store，不写盘）。

不按行内 sessionId 重键：两条 JSON 记录可以带同一个 sessionId，INSERT OR REPLACE 会让后写的 closed 幽灵覆盖活行；导入只跑一次、JSON 随后冻结，这一步不可逆。改为按文件原 key 导入，错键行保持不可达（身份扫描本就跳过 key 与 sessionId 不符的行）。

3. close / reactivate / mojo journal：先落盘，再合并回内存

原先在活对象上就地修改，失败再逐字段还原（close 14 个字段、reactivate 20 个、mojo 2 个）。改为：

const next: Session = { ...session };
next.status = 'closed';
persistRow(next);             // 抛错 → 内存未改
Object.assign(session, next); // 提交后才落内存

用 Object.assign 而不是替换 map 引用，保留 DaemonSession 的共享别名。既有三条回滚回归（Remote lineage / previewTarget / mojo park）断言未改，继续绿。

4. 读写方式打开会创建空库

new DatabaseSync('<missing>.db') 会把文件建出来；空库让 existsSync(db) 为真、跳过 JSON 导入，迁移前的会话从所有活路径上消失。

• openDbForRead 对不存在的路径直接抛错
• withOwnStoreDb 复用 loadForWrite() 已附着的连接，不再自开
• mutateSessionRowOffline 的 sqlite 路径在 openDbForOwnStore 前再 existsSync 一次，缺文件返回 undefined

5. 删除已失效的等待上限参数

Remote 批量 API 的 options.maxWaitMs 删除：它约束的是 JSON 文件锁的等待，SQLite 路径上从未生效。等待上限由连接级 busy_timeout（3s）决定。fleet shutdown 的 remaining <= 0 预检保留。

6. 沙盒授权

readOnly 授权为「session-stores/<appId> 目录 + 冻结的 sessions-<appId>.json」。授目录而不是三个文件，是因为单文件 bind 会钉死 WAL sidecar 的 inode，而 SQLite 在 daemon 重启时会删建 -wal/-shm——长驻的沙盒面板会一直读着已死的 WAL。兄弟 bot 的 store 目录仍 deny-by-default；测试补了 sibling 目录、共享父目录、spawn 之后才出现的库三条 none 断言。

升级窗口内沙盒里的 botmux send 仍要 stat 得到那份冻结 JSON，所以该授权暂不撤。

7. 删除白板：daemon 在走 IPC，不在才离线写

clearSessionWhiteboardRefs 原先按 sessions*.json 筛文件名再整份改写。#852 之后行已在 SQLite，扫描匹配不到文件，deleteWhiteboard 返回 clearedSessions: 0，而 whiteboardId 仍指向已删的板。

改为走 store 后还有三个问题要收：

• 解绑必须按板 id 比对。 删板会先把板移出 index，daemon 的 ensureSessionWhiteboard 因此会在该会话下一轮立刻补一块新板。无条件发 whiteboardId=null 会把这块新绑定一起抹掉，并留下一块没人指向的孤儿板。路由新增 expectWhiteboardId，不匹配返回 409；离线路径本来就有比对，两侧口径现在一致。
• 未能解绑要报出来。 daemon 可见但 IPC 不可用时，离线写会被存内探测中止——这是对的（不能绕过持有内存缓存的 daemon），但结果不该和「没有会话引用这块板」一样报 0。这类会话计入 unresolvedSessions 返回。
• IPC 要有超时。 心跳新鲜但 socket 不响应的 daemon，不能把 dashboard 的删除请求一直挂住。

行为分支：daemon 运行中 → IPC 带 CAS 解绑；daemon 不可见 → 离线写；IPC 失败且 daemon 仍可见 → 不写盘，计入 unresolvedSessions。

8. 离线写与 daemon 发现各收敛成一份实现

新增 services/session-offline-write.ts#mutateSessionRowWhenUnowned：把「离线写的前提是没有 daemon 持有这一行」收成一个入口，cli.ts 与 whiteboard-store 共用，探测与 store 读写用同一个 dataDir。此前每个调用方各自拼一遍 abortIf，本 PR 的白板路径第一版就漏了。

cli.ts 私有的心跳目录解析与 90s 过期判定（与 utils/daemon-discovery.ts 逐字重复）删除，改用共享实现；listOnlineDaemons / findOnlineDaemon 增加可选 dataDir 参数。设计文档 Stage 1 要求「心跳探测不再作为所有权判断」，收敛后只剩一个入口要删。src/cli.ts 净 −38 行。

9. 冻结的 JSON 文件

磁盘上原地保留、不改名。daemon 导入后运行时不再写它；升级窗口内其它进程仍可能读；它也是回退到迁移前版本时的数据副本。改名会让回退后的旧 daemon 从空库起步，再写出一份新 JSON。

---

一并修复的三个 #852 遗留问题

A. Bun 上导入发布出只有文件头的库

暂存库开着 WAL，而 renameSync 只搬走主文件。bun:sqlite 关连接时不把 -wal 折回主文件，行留在 sessions.db.tmp-wal 里，发布出去的是 4 KB 的文件头；之后每次打开报 disk I/O error。导入门是 existsSync(db)，这个壳不会被重建——迁移前的会话在所有活路径上消失。

	修复前	修复后
Bun 1.4.0（本分支）	sessions.db=4096 + 孤儿 tmp-wal/tmp-shm，listSessionsStrict() 抛 disk I/O error	sessions.db=24576，行可读回，无 tmp 残留
Bun 1.4.0（master）	同样复现（#852 起导入逻辑未变）	—
Node 24	正常	正常

暂存库改用 PRAGMA journal_mode = DELETE，正式库仍是 WAL。

master 上跑编译版、且该 bot 还没完成过导入的安装会踩到。若本 PR 合入偏慢，这一处可以单独先合。

B. 删除白板后 whiteboardId 仍指向已删的板

见上「7」。原因是按文件名筛 sessions*.json 的扫描在 #852 之后匹配不到任何文件，而测试夹具当时写的正是 JSON，所以一直绿。

C. Node 22 加载 node:sqlite 时向 stderr 打出 ExperimentalWarning

ExperimentalWarning: SQLite is an experimental feature and might change at any time

pty 合流后这两行进入 botmux list 的备用屏，把钉住的标题挤出第 0 行；CI（Node 22）上 picker 断言读到空行。Node 24 已不发此警告，本机 24 复现不了。#852 之后凡是打开 .db 的 CLI 都会污染 stderr，本 PR 让 botmux list 也打开库，才在 CI 暴露。

修法是在 sqlite-compat 的 require 期间过滤该警告，require 结束即还原——process.on('warning') 拦不住 Node 的默认打印。回归：test/sqlite-compat-warning.test.ts（Node 24 上恒绿，真正的拦截在 CI 的 Node 22）。

---

身份扫描

readSessionRowCopiesAcrossStores 要求恰好一份。legacy → per-bot 一直是复制而不删除，导入完成后若把冻结 JSON 也算一份，会把合法会话判成重复。本 PR 在已有 .db 时不再把同一 bot 的冻结 JSON 算作第二份。

未导入、尚无 .db 时 JSON 回落仍在，sessions-evil.json 这类按文件名冒充 store 的路径并未从窗口内消失。

---

升级窗口

初版曾把跨进程也改成只读 SQLite，前提是「灰度已关闭」。这个前提不成立：npm i -g 的 postinstall 会立刻改写 ~/.botmux/bin/botmux，而 daemon 仍跑着旧代码；自动更新默认关闭，botmux upgrade 只提示用户自己 botmux restart。窗口没有上界，每个从 JSON 写者升级上来的用户都会经过一次。

同一份仅有 JSON 的数据目录，逐项对照：

窗口内操作	master	跨进程 db-only（已撤回）	现在
CLI 快照读（botmux send / list）	['s1']	抛错	['s1']
CLI 点读	LIVE	undefined	LIVE
身份扫描	1 份	0 份	1 份
worker getSession	LIVE	undefined	LIVE
worker getSessionFresh	LIVE	undefined	LIVE
CLI 离线写	ok → closed	抛错	ok → closed

所以只删 daemon 的 JSON 写路径。跨进程读、离线写、owner: false 的只读 load、沙盒对冻结 JSON 的授权都保留。删除这些分支的条件写在设计文档 Stage 0：升级后自动重启 fleet 落地，或 2026-11-26 的兜底复核点。

老版本升到本版并重启 daemon 后，一次性导入仍会带上 active 与 closed 行（有回归覆盖）。

---

影响面

• 主要改 session-store、whiteboard-store、dashboard-ipc-server；新增 services/session-offline-write.ts；另及 cli.ts 的 daemon 发现、utils/daemon-discovery.ts、fs-policy、remote-shutdown-detach 的调用签名。
• 跨进程：daemon 在线时写 SQLite；worker owner: false 走 db-else-json 只读、不建库；CLI 离线写在已有 .db 时走 BEGIN IMMEDIATE + 心跳探测（SQLite 锁不替代「daemon 内存与磁盘分叉」的探测），未导入则写 JSON；跨 bot 发现同样 db-else-json。dashboard 删白板：daemon 在则 IPC 带 CAS 解绑，不在才离线写。
• 跨平台：Linux bwrap / macOS Seatbelt 仍授 store 目录（单文件 bind 会钉死 WAL sidecar 的 inode）。
• 跨 CLI / 后端 / 会话类型：updateSession 等签名不变；Pty/Tmux、话题会话/群会话、adopt/restore、sandbox on/off 仍走同一套 store 导出。
• cli.ts 的 daemon 发现换实现：约 35 处调用点行为不变（同一个心跳目录、同样的 90s 过期、同样的字段），差异只在数据目录改为显式传入。
• 旁路存储未改：turn-sends / frozen-card / whiteboard 正文 / usage-ledger / idempotency / vc-meeting-* / schedule / pending-turn journal；utils/file-lock.ts 本体未动。
• occupancy（库内租约）和单一 apply 不在本 PR。心跳探测在 CLI 离线写与删白板离线路径上保留。

---

已知边界

• 离线写在 SQLite 路径只改一行，不再顺手删除错键行。
• 跨进程 JSON 读分支仍在（约 25 行）。删除条件见设计文档 Stage 0，不是「感觉灰度稳了」。
• Remote 批量的等待上限固定为 busy_timeout 3s。
• restoreActiveSessions 仍走 listSessions()：损坏库会被当成空投影启动（写路径有 listSessionsStrict）。与 feat(session): session-store 引擎替换为 per-bot SQLite（导入 + 混合窗口 + sqlite-compat） #852 相同，本 PR 未改。
• 删白板时若某个会话的 daemon 可见但 IPC 不可用，该行的绑定会留在盘上指向已删的板。它不是坏数据：daemon 的 ensureSessionWhiteboard 会在该会话下一轮补上新板。本 PR 只保证这种情况被计数报出，不静默。

---

测试与验证

未跑 switch:here，未重启 live daemon。

• tsc --noEmit -p tsconfig.json 干净；bun run build 通过。
• CI 全绿（build / bun-binary / bun-binary-musl / CodeQL / 三个 Analyze）。build 在 Linux + Node 22 上跑完 18746 条。
• 全量单测在 Node 22（CI 版本）、两侧都先 bun run build，与 merge-base origin/master@cc5085b6 本机同环境对照：baseline 37 条失败（全部环境性，e2e / 权限位 / 端口一类），本 PR 39 条，差集 2 条，都在 test/mojo-close-admission-fence.test.ts。
  这两条判定为本机满载下的抖动，依据：失败点是 vi.waitFor 的默认 1s 超时在等 fake mojo 子进程的 stdout（expected undefined to be 'sid-torn'）；隔离重跑 3/3 通过；CI 在本 PR 最终 commit 上跑同两个文件通过。CI 也曾在中间 commit 上红过同族的 test/mojo-close-worker-journal.integration.test.ts 一次，rerun 同一 commit 即通过。
• test/session-store.test.ts + test/session-store-sqlite.test.ts 全绿。
• 白板解绑：test/ipc-whiteboard-route.test.ts、test/whiteboard-unbind-session.test.ts 全绿。
• Bun 1.4.0 与 Node 24 各跑一次真实导入：均为 24576B、行可读回、无 .tmp 残留（修复前 Bun 上是 4096B 空壳 + 孤儿 sidecar + disk I/O error）。
• git merge-tree origin/master HEAD 无冲突。

对照方法上漏过两次：① 没先 bun run build，依赖 dist/ 的测试被跳过，没看到白板绑定清不掉；② 本机 Node 24，没看到 ExperimentalWarning。最终口径是同版本 Node + 两侧都 build + 逐条 diff。

新增回归覆盖：升级窗口内的 snapshot / 点读 / 身份扫描 / worker 读 / 离线写；owner: false 的 load 只读；botmux delete 在仅有 JSON 时写回 JSON 且不建 .db；snapshot 与离线写都不创建 store；已导入 store 的冻结 JSON 不算身份扫描第二份；导入时剥掉 legacy 卡片字段；同 sessionId 的两行不得互相覆盖；白板解绑的 CAS、409 不回落写盘、IPC 失败计入 unresolvedSessions、无 larkAppId 的 legacy 行不探测 daemon。

夹具：seedPersistedSessionRows / sessionStorePath 播种真实 SQLite。断言数量只增不减。

---

与其它 open PR

session-store.ts 上还有 #925 / #1001 / #956，base 都在 #852 之前，本来就需要 rebase。

#925 要解决的是 save() 每次序列化整个 map、closed 行只增不减、撞上 V8 字符串上限。本 PR 删除 save() 之后行级 upsert 是 O(1)，那条立项理由不再成立。若仍要回收 closed 行，应该是 DELETE FROM sessions WHERE status='closed' AND ...。

#1001 / #956 只加函数，rebase 即可。