persistence: bbolt / pebble / Postgres backends (goals, not gaps)

[suraciii]

The store currently ships the in-memory and SQLite backends only. bbolt, pebble, Postgres, and others remain goals or candidates — design/persistence.md's Gap section states they are not current implementations, so this is not a gap and not a defect. Deliberately low priority, deliberately un-milestoned.

Spec: the "Gap" section of design/persistence.md.

Acceptance

• A new backend implements the store interface behind the existing I/O seams and gets the same test coverage as SQLite.

[suraciii]

维持 ROADMAP「Not a step: other storage backends」的结论，但记下唯一可能推翻它的那条证据，免得日后重新论证：

research/embedded-store-bench.md 的实测里，单实体热路径（gor 的 per-key 串行模型）上 SQLite(FULL) 与 bbolt 持平、Pebble 更慢；但 64 worker 多 key 并发写上 Pebble 约 45×（SQLite-FULL 403 ops/s vs Pebble 18,112 ops/s）。

这张表测的全是 FULL 耐久的后端，没有 SQLite-Relaxed 的数。#81 的 Relaxed 档去掉每次 commit 的 fsync、只在 WAL checkpoint 时 sync，高并发下 checkpoint 的 sync 被多个 writer 摊薄——Relaxed-SQLite 在 64 worker 上极可能远好于 403 ops/s，可能抹平大半差距。

触发条件：等 #81 落地、Relaxed 档的 state-write 数字进 benchmarks.md 之后，拿它和上面这张表一起重评。若 Relaxed-SQLite 在真实多实体负载下仍显著落后、且出现真实用户痛点，这条才从「目标」升格为「步骤」。在此之前维持不挂里程碑。