fix(memory): 增量向量化 + 单分片逐条隔离，召回请求数降一个数量级（M61）

M15（2026-10-13）登记的两条放大源落在记忆层，本次一并收口：

1. 整理轮/入库审查**只嵌增量**：新加 vector.Index.Vectors（SQLite/PG 实现，
   按 id 取已存向量、维度不符当未命中），Store.embedIncremental 先复用索引里的
   向量、只嵌缺的那些，并把手算出的向量回填索引 ⇒ 同一分区第二轮起零请求。
   判据写明为「向量存在性 + 维度一致」（正文在本仓不可就地改写，故无需哈希）。
   维度与当前 embedder 不一致时禁用复用并 WARN（不混两种表示）。
2. 嵌入链对单个慢分片有韧性：embedIsolated 整批失败后逐条隔离，坏的那几条
   记缺口、其余照常返回；一条都没拿到才报错降级。请求数上界 1+B（B=8 ⇒ 9），
   服务整体挂死时一次即收手，不用「请求放大」换韧性。
3. 缺口/复用/回填条数进日志（缺口走 WARN），review 的被审条目拿不到向量时
   如实返回错误 ⇒ 走既有词项余弦降级（不把「算不出来」说成「没有重复」）。

请求数（单测内假 OpenAI 兼容服务端计数，生产 API embedder + 真 SQLite 索引）：
  24 条存量：修复前每轮 3 → 第一轮 3、第二轮 0
  12 条分区整理轮：第一轮 2 → 第二轮 0
  20 条候选的入库审查：26（201÷8）→ 第一条 3、第二条 0
  一条坏正文：保住 7/8 条，代价 9 个请求；整体性故障 9 个请求后收手

internal/runtime/memory/tidy_config.go

@@ -87,9 +87,11 @@ const (
 	//     同样的分区 500 → **250** 个请求、审查链 51 → **26** 个请求，而单请求实测最大
 	//     1.782s，仍在 5s 之内（16 条/片已复现出 11.043s 的越界单请求，故不取更大）。
 	//
-	// ⚠️ 但它**不缩短整理轮的墙钟**：链路耗时由「条数 × 每条成本」主导，批次只改请求
+	// ⚠️ 它**不缩短整理轮的墙钟**：链路耗时由「条数 × 每条成本」主导，批次只改请求
 	// 数（实测 201 条在 4 条/片与 8 条/片下都是 ~21s）。「整理轮每轮把整个分区重新
-	// 向量化」这个**放大源仍然存在**（user 分区一轮 250 个请求），本切片不动它。
+	// 向量化」这个放大源由**增量向量化**收口（embed_incremental.go，2026-10-30）：
+	// 索引里已有向量的行不再重嵌、算出来的向量回填索引，因此同一分区**第二轮起**
+	// 的请求数趋近 0（第一轮仍按 ⌈条数/批⌉ 发，那是把向量算出来的一次性成本）。
 	//
 	// 批上限在 embedder 内部**还有一道强制**（Embed 自己切片），因此这里即使被改大
 	// 也不会把服务端顶住；这一行只是让调用方别去构造注定被切开的超大切片。