feat(memory): 护栏抬高+时间预算闸+试算加性异步 与 D3 入库前审查（耦合两片一起落）

【MT-A：护栏 + 诚实截断 + 试算异步】
- maxTidyCompareItems 400(写死)→2000 并开放为 MEMORY_TIDY_COMPARE_LIMIT；
  MEMORY_TIDY_CANDIDATE_LIMIT 默认 20→200（语义不变，仍每分区）
- 依据是首跑实测：459 条的分区被 400 截断 ⇒ compared(705) < scanned(784)，
  候选数(77)由上限而不是规则决定；三处上限的 WARN 都补齐了总数/上限/分区名
- 新增「上限 + 时间预算」双闸（实测 2000 条/分区 ≈234s > 3 分钟墙钟）：
  整分区跳过 / 两两比对中途收手，一律如实记 (budget) + WARN
- ?async=1 ⇒ 202 {runId,status}；GET …/{runId} 轮询（writeAuth 同档）；
  done 的 result 与同步 data 逐字节同形；并发=复用既有 runId、TTL 30min 自完成起算、
  重启即如实 404 tidy_run_not_found；不带 async 时同步路径逐字不变

【MT-B：D3 入库前审查（design/23 §15.1）】
- 新记忆经 Store.Add（仓库里唯一 INSERT INTO memory_items）落库后，由独立记忆管理
  会话（sess-memorytidy）在有界后台队列异步判定 skip/merge/modify/create
- 软合并回写（status + merged_into/merged_from/merge_count，可 revert、绝不改 content）
- 隔离来源（群聊/陌生人）**概不审查**、召回/超时失败**零改写**（fail-safe 结构性成立）
- 写入侧仅 +62.7µs/条（非阻塞入队）；默认 ENABLED=true（主人裁定：入库前先审查）

【耦合说明（重要）】两片同包且互相依赖：MT-B 的 preinsert_recall.go 用 MT-A 的
collectTidyPairs 新签名 + tidyBudget ⇒ **各自单独都 build 不过**，故一并落地。
MT-A 为让整包编译，最小幅度适配了 MT-B 的 preinsert_recall.go / preinsert_test.go
（零值预算=行为不变；符号重名改名）。

【我的验收】隔离 worktree（37 文件）build/vet/linux/darwin 全过，切片包全绿；
我亲手打红两个变异：① 去掉 (compare) 截断标记 ⇒ TestTidyCompareLimit_HitIsLoud 红；
② 中和隔离来源守卫 ⇒ TestReviewRestrictedSourceIsNeverTouched 红。
唯一红是 internal/runtime/tool 的两条超时用例（该包无人改）⇒ 主仓库 -count=8 全绿，
判定为负载敏感 flake（当时两个整树验收 + 子代理并发），已记入开发习惯与约定 §7。

.env.example 补 MEMORY_REVIEW_* 四键（MT-B 无该文件权限，由我按其代码语义补写）。

internal/runtime/memory/tidy_config.go

@@ -45,14 +45,19 @@ const (
 	// defaultTidyScanLimit 是每分区每轮的扫描上限（design/23 §9）。
 	defaultTidyScanLimit = 5000
 
-	// maxTidyCompareItems 是每分区每轮**真正参与两两比对**的条目上限。它是
-	// 本实现的性能护栏：两两相似度是 O(n²·dim)，5000 条会到十亿级乘加，
-	// 低峰任务也不该跑成那样。超限时按「最新优先」截断并记一条 WARN
-	// （绝不静默），见 tidy_recall.go。
-	maxTidyCompareItems = 400
+	// maxTidyCompareItems 是每分区每轮**真正参与两两比对**的条目上限的兜底默认
+	// 值（可直接从 MEMORY_TIDY_COMPARE_LIMIT 调，见 TidyConfig.CompareLimit）。
+	// 两两相似度是 O(n²·dim)，5000 条会到十亿级乘加，低峰任务也不该跑成那样。
+	// 2026-10-06 由 400 抬到 2000：首轮真跑 459 条的分区被旧值截到 400，
+	// 于是 compared(705) < scanned(784) —— 截断确实如实登记了，但护栏成为结
+	// 果的主因本身就是缺陷。超限仍按「最新优先」截断并记一条 WARN（绝不静默），
+	// 见 tidy_recall.go。
+	maxTidyCompareItems = 2000
 
 	// defaultTidyCandidateLimit 是每分区每轮的候选上限（design/23 §9）。
-	defaultTidyCandidateLimit = 20
+	// 2026-10-06 由 20 抬到 200：首轮真跑四个分区同时打满旧值 ⇒ 候选数由
+	// 上限而不是规则决定（77 是下限）。
+	defaultTidyCandidateLimit = 200
 
 	// tidyLowConfidenceThreshold 是置信度否决门（design/23 §5.2-6）：
 	// confidence 不能当合并门（[2]0.7 与 [5]0.8 是同一事实），但必须当否决门。
@@ -90,6 +95,9 @@ type TidyConfig struct {
 	ScanLimit int
 	// CandidateLimit 是每分区每轮候选条数上限。非正用默认值。
 	CandidateLimit int
+	// CompareLimit 是每分区每轮真正参与两两比对的条目上限（性能护栏）。
+	// 非正用默认值（maxTidyCompareItems）。
+	CompareLimit int
 }
 
 // TidyConfigFromConfig 把 config.MemoryTidyConfig（env 侧旋钮）映射成
@@ -103,6 +111,7 @@ func TidyConfigFromConfig(cfg config.MemoryTidyConfig) TidyConfig {
 		RecallThreshold: cfg.RecallThreshold,
 		ScanLimit:       cfg.ScanLimit,
 		CandidateLimit:  cfg.CandidateLimit,
+		CompareLimit:    cfg.CompareLimit,
 	}
 }
 
@@ -127,6 +136,9 @@ func normalizeTidyConfig(cfg TidyConfig) TidyConfig {
 	if cfg.CandidateLimit <= 0 {
 		cfg.CandidateLimit = defaultTidyCandidateLimit
 	}
+	if cfg.CompareLimit <= 0 {
+		cfg.CompareLimit = maxTidyCompareItems
+	}
 	return cfg
 }