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/preinsert_config.go

@@ -60,6 +60,13 @@ const (
 	//
 	// 🔴 与设计稿的对齐（如实登记）：design/23 §15 那一行原写 `Timeout=20s`（本次改动
 	// **之前**的口径），已按上面实测同步为 `Timeout=90s`。
+	//
+	// 🆕 2026-10-30（M61）：链长已由**增量向量化**压到「只剩缺向量的那几条」——
+	// 同分区第一条审查 ⌈K/批⌉ 个请求、之后 **0 个**（候选从 `vec_items` 取，
+	// 见 preinsert_recall.go 的 embedReviewTexts 与 embed_incremental.go）。因此上面
+	// 的 90s 从「必须覆盖链长」变成「远大于链长的余量」；**不下调**是刻意的：
+	// 单请求在并发下仍会偶发越过 5s（embedding/budget.go 文件头 ④ 的实测），余量是
+	// 韧性而不是浪费 —— 慢分片现在由 embedIsolated 逐条隔离，不吃满整条预算。
 	defaultReviewTimeout = 90 * time.Second
 	// reviewAuditWho / reviewAuditVerb 是审查留痕的审计口径：它是**系统任务**，
 	// 不是任何角色（design §4.1 C 的同一理由）。