fix(memory): 面板调优引入的两处运行期写入面收口（-race 修前红 → 修后绿）

一、审查档（preinsert.go / preinsert_gate.go）：面板调优会在**运行期**改 cfg 的
两个字段（DisableIngestGate / TempTTL），而读这两个字段的两处不持锁
（gateEnabled 在同步入库闸上、deferDeadline 在第五态 defer 上）。
- 读侧改走新的 tuningSnapshot()（r.mu 由 Mutex 换成 RWMutex，读锁下取整份快照）；
- **只**收这两个字段的读点：其余读点读的是构造期冻结的字段，不与写方交手，
  故刻意不给入库热路径加无谓的锁；注释写明「将来面板再接管别的字段，那些读点
  必须与它一起收」；
- 锁序：写方持锁期间只做字段赋值、不取任何别的锁（normalize/回落都在取锁之前
  跑完）⇒ 不引入新锁序。

二、整理档（tidy_service_tuning.go）：修掉我自己的那条真竞争 —— 原顺序是
「Stop → Start → 写 cfg」，而新起的循环**立刻**读 s.cfg 重算下一拍，与写入并排
（那一拍还可能按旧配置算出来）。改成「Stop → 写 → Start」。
顺带去掉 Stop 的超时分支：超时意味着 wg 的 Wait 仍在飞，紧接着 Start 的 Add 会
踩上 M3 在 tidy_service.go 明文写下的 WaitGroup 复用纪律（-race 下 panic）；`Stop`
期间也不持 runMu，避免与「心跳正要开跑一轮」互相等死。

证据（全部逐条跑过再还原，还原用 diff 逐字校验为 0 差异）：
- 审查档：撤回读侧修复 ⇒ 2 处 DATA RACE（写 preinsert_tuning.go 的两个字段 × 读
  gateEnabled / deferDeadline）；恢复 ⇒ 绿。
- 整理档：把顺序改回「先起后写」⇒ DATA RACE（写 applyTidyConfig × 读 nextDelay）；
  恢复 ⇒ 绿。
- 新增两条只在 -race 下有意义的回归哨兵（tidy_service_tuning_test.go）：审查档真
  并发读写；整理档用**真心跳**当读者（不伪造生产不存在的调用方，那个入口在包里
  只有心跳 goroutine 会调）。

热路径成本：新增的同步是「一次无竞争 RLock + 整份小结构体快照」，隔离实测约
4ns/次（5e6 次共 22.9ms）；入库闸那条测量用例的批均值在 2.62ms → 2.71~2.81ms
之间波动，落在那条用例自身的运行间噪声里（同一份代码连跑两次，纯写入基线就从
39µs 飘到 60µs）。

internal/runtime/memory/preinsert_gate.go

@@ -237,7 +237,7 @@ func (r *PreInsertReviewer) planFromVerdict(item MemoryItem, v ingestVerdict) in
 // 闸（同步）与异步审查层**共用这一个函数**：同一份配置、同一种时刻语义，因此
 // 同一条记忆无论被哪一层判成 defer，拿到的有效期都来自同一个算式。
 func (r *PreInsertReviewer) deferDeadline(now time.Time) time.Time {
-	return now.UTC().Add(r.cfg.TempTTL)
+	return now.UTC().Add(r.tuningSnapshot().TempTTL)
 }
 
 // failOpenPlan 组装 fail-open 计划：照常插入（active）+ 投既有队列 + 留痕。