examples: 共享 SQLite 的多进程并发写冲突路径没有自动化覆盖

[suraciii]

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 之后。

[suraciii]

归位：这条守的是集群承诺（收敛窗口内双激活并发写同一记录、ETag 让输家失败），issue 自己写明「这个行为单节点永远不会出现」。产品方向转向单机之后，它属于已发布的可选扩展上的测试缺口——承诺本身是被守住的（13% 轮次返回 store: etag conflict 就是证据），缺的是自动化覆盖：net 测试用 store.NewMemory，DST 用 fake store，真共享 SQLite 文件的冲突路径无人守。

低优先级，继续不挂里程碑。要做也只是一个 -tags net 测试，同进程双 runtime 共享一个 SQLite 文件即可触发，范围 issue 正文已经限定好了。