examples/shadow/cluster_net_test.go（#72 加的）用 store.NewMemory，两个 runtime 在同一进程里。
而多节点最容易咬人的那条路径——收敛窗口内双激活并发写同一记录、ETag 让输家请求失败——出在真实共享 store 上，net 测试碰不到。
取证（#72 的审查）：15+ 轮多进程运行里，约 13% 的轮次有请求返回 500：
device-20 -> [{"error":"store: etag conflict"}]
这个行为单节点永远不会出现（单激活 + mailbox 串行化）。它现在只被文档里的一段话描述，没有任何测试守着。
要做的
加一个 -tags net 测试，用 store.OpenSQLite 让两个 runtime 共享同一个 SQLite 文件，把冲突路径逼出来并断言其语义（失败是冲突错误，不是静默覆盖；重试之后收敛）。
不需要真多进程——同进程双 runtime 共享同一个 SQLite 文件就够触发。
注意
/tmp 是 tmpfs。这个测试不测 fsync，放哪都行，但别顺手在里面加持久化耗时断言。
排在 #72 之后。
examples/shadow/cluster_net_test.go（#72 加的）用store.NewMemory，两个 runtime 在同一进程里。而多节点最容易咬人的那条路径——收敛窗口内双激活并发写同一记录、ETag 让输家请求失败——出在真实共享 store 上，net 测试碰不到。
取证（#72 的审查）：15+ 轮多进程运行里，约 13% 的轮次有请求返回 500：
这个行为单节点永远不会出现（单激活 + mailbox 串行化）。它现在只被文档里的一段话描述，没有任何测试守着。
要做的
加一个
-tags net测试，用store.OpenSQLite让两个 runtime 共享同一个 SQLite 文件，把冲突路径逼出来并断言其语义（失败是冲突错误，不是静默覆盖；重试之后收敛）。不需要真多进程——同进程双 runtime 共享同一个 SQLite 文件就够触发。
注意
/tmp是 tmpfs。这个测试不测 fsync，放哪都行，但别顺手在里面加持久化耗时断言。排在 #72 之后。