fix(memory): extend background-maintenance lock discipline to the periodic prepare path (issue #324)

[LeXwDeX]

背景（issue #324 debt 2）

审计报告：docs/audit-dag-memory-goal-2026-08-18.md（MEM-01 / MEM-02 / MEM-03）。

周期 prepare 在 fence.withLiveIdentity + lock.withProject 之下内联跑周期维护（2 次模型调用）——违反模块自己在 memory.ts 注释中成文的锁纪律（"模型调用在 fence/lock 之外"）。叠加 #329 退役墙钟后，一条持续流式的慢推理调用可以把跨进程 identity fence 持有任意长时间，饿死并发的 /compact checkpoint、memory_search、worktree admission 与 identity upgrade（EffectFlock 等待者 5 分钟后 LockTimeoutError）。

变更

memory.ts

• prepareUnsafe 镜像 checkpointUnsafe 形状：due 维护在 fence 之后经 kickMaintenance 后台运行（每项目至多一个在飞作业）；prepare 渲染维护前快照，提交结果在后续 prepare 浮现（fix(memory): SSE-liveness debt — wall-clock guard contradicts streaming principle; periodic prepare path still long-holds locks #324 明示语义）。
• due-only 轮次（shouldMatch=false）不再读 store、不拿 fence/lock——纯内存节奏记账。
• 删除不再被调用的 maintain（裸 store.updateTopics、依赖调用方持锁的旧形状）。
• searchUnsafe：行为不变（fix(memory): SSE-liveness debt — wall-clock guard contradicts streaming principle; periodic prepare path still long-holds locks #324 验收要求保留同查询合并），把"matcher 有意在锁内运行以合并同查询"这一取舍显式写进注释。
• MEM-03 部分收敛：渲染"维护前快照"从 catchCause 的瞬态行为变为 CONTEXT.md 声明的设计语义；"失败仅 logWarning、未向用户暴露"的一半仍在，留待 follow-up。

CONTEXT.md 增补两条不变量：维护永不跨模型调用持锁；search 跨单次有界 matcher 调用持锁是已声明的取舍。

测试

• 调整被钉死的"周期维护同步"语义：runs due maintenance without refreshing retrieval context for a later turn 改为 polling 等待后台维护完成（fix(memory): SSE-liveness debt — wall-clock guard contradicts streaming principle; periodic prepare path still long-holds locks #324 预告的调整）。
• 新增回归 keeps the fence and project lock free while background maintenance streams：维护模型调用在飞期间，并发 checkpoint（需要同一 fence+lock 的渲染 select）必须在 2s 内完成——旧内联形状下会饿死在 fence 上。
• coalesces concurrent identical queries without consuming another query slot 原样通过（搜索合并行为未变）。

验证

• bun typecheck（packages/opencode）✅
• bun test test/memory test/tool/memory-search.test.ts：96 pass / 0 fail ✅
• bun test test/server/httpapi-memory-wiring.test.ts test/session/system.test.ts：10 pass / 0 fail ✅