fix(memory): 清掉两处与实现相反的旧说法 + 并发哨兵改成窗口重叠（变异 8/8 红）

review P2 两条。

① 旧说法没删净（同类第 N 次：改了 A，同一主张还留在 B / C）。这次按「**这句主张的所有
落点**」重扫了一遍我这一片里含 Stop / Start / 重启 / 心跳已停 的注释，改掉两处与实现
正面打架的：
- applyTidyConfig 的注释还写着「调用方（ApplyPanelTuning）在 Stop 期间不能持 runMu」
  「前提仍是心跳已停」—— 而同文件的文件头刚写过「调优路径上一个 Start/Stop 都没有」，
  同一文件里两段话自相矛盾；
- 整理档那条并发哨兵的循环注释还写着「Stop 把 running 置为 false，忘了重启就会静默
  停摆」，而该循环里根本没有 Stop/Start（改成「唤醒不是停表」，并把 Stop/Start 那版
  明确标成旧版）。
顺带把文件头「所有读点都收进访问器」的说法改准：此外还有一处**同一把锁下**的相等比较
（ApplyPanelTuning 里的 s.cfg == next），它本身不需要访问器。

② 新哨兵是概率性守卫：固定 40 轮时撤回 DryRun 同步只红 4/8（写方那几十次覆写在微秒级
就跑完，读方还在慢端点里打转）⇒ 文档规定的 -count=1 会漏掉约一半回归。改成**两侧各自
跑满同一个 300ms 墙钟窗口**（写窗口与读窗口必然重叠，不靠快慢概率），读方两个活端点各
起两路；写方每轮换一个值（否则 ApplyPanelTuning 会被「配置没变」的早退挡掉，根本不写）。
实测：撤回 DryRun 同步红 **8/8**、撤回 ManualRun 同步红 **8/8**（各 8 次 -race -count=1）；
干净 tip `-race -count=5` 全绿、三条哨兵一起 `-count=3` 全绿；该哨兵耗时 0.35s（原 0.18s）。

顺带把 clipJSON 用例注释里那句改准：40 字节处被切掉的是第 13 个汉字的**第三个字节**
（前两个字节被留下），而不是先前写的「第三个字节上」。

internal/runtime/memory/tidy_service_tuning.go

@@ -48,10 +48,11 @@ import (
 // Wait has returned`）。唤醒通道把这两件事一起消掉：**调优路径上一个 Start/Stop 都没有**。
 //
 // 并发口径：`s.cfg` 由 `s.mu` 互斥 —— 🔴 **按字段扫，不按文件扫**：这个字段既然会被
-// 运行期整体覆写，它的**每一个读点**都必须与写方同步，因此所有读点都收进了持锁访问器
-// （`enabled()` / `cfgSnapshot()` / `scheduleSnapshot()`：调度读 `nextDelay` /
-// `dueNow`、两个活端点的开关判定 `DryRun` / `ManualRun`、以及 `Enabled()` 与 `Start`
-// 的启动日志）。写 `tidier.cfg` 则与**所有轮次**由 `s.runMu` 互斥（心跳轮、手动轮、
+// 运行期整体覆写，它的**每一个**读点都必须与写方同步。做法是读写都在 `s.mu` 下：读点
+// 收进三个访问器 `enabled()`（开关）/ `cfgSnapshot()`（整份）/ `scheduleSnapshot()`
+// （整份 + lastRun），覆盖调度读 `nextDelay` / `dueNow`、两个活端点的开关判定
+// `DryRun` / `ManualRun`、`Enabled()` 与 `Start` 的启动日志；此外 `ApplyPanelTuning`
+// 里还有一处**同一把锁下**的相等比较（`s.cfg == next`），它本身不需要访问器。写 `tidier.cfg` 则与**所有轮次**由 `s.runMu` 互斥（心跳轮、手动轮、
 // 试算都持它）。因此这里只剩下「持两把锁写 → 发一次唤醒」，不与任何既有锁序冲突。
 
 // ApplyPanelTuning 把面板值当场叠到运行期（见文件头三条口径）。
@@ -197,8 +198,9 @@ func tidyPanelTuning(base TidyConfig, panel runtimeconfig.MemoryTidyTuning, log
 //
 // 两处都要写：只写前者 ⇒ 轮次仍用旧阈值；只写后者 ⇒ 调度仍按旧周期。
 //
-// 它自己拿 `runMu`（排除并发的一轮：心跳轮与手动轮 / 试算都持它），因为调用方
-// （ApplyPanelTuning）在 `Stop` 期间**不能**持它。前提仍是「心跳已停」：调用方负责。
+// 它自己拿 `runMu`（排除并发的一轮：心跳轮与手动轮 / 试算都持它）—— 调优路径**不等
+// 任何后台件停**：`s.cfg` 的读点全部持 `s.mu`（见文件头），`tidier.cfg` 的读点全部持
+// `runMu`，因此这把锁足以让写入与每一轮的读不交手，不需要（也不再）停心跳。
 func (s *TidyService) applyTidyConfig(cfg TidyConfig) {
 	s.runMu.Lock()
 	defer s.runMu.Unlock()