test(core): 修偶发红的 rtchild 用例，登记另一处未修的

## 背景

CI 的 `-race` 门两次变红（提交 `merge: pr31` 与 `style(webui)`），
都是 `TestRTChild_InterruptTruncatesOutput`：

    --- FAIL: TestRTChild_InterruptTruncatesOutput (5.00s)
        rtchild_r3_test.go:271: 等待超时：开始输出

本地 `-race` 单测 6/6、整包连跑 4 轮全过，复现不出来。

## 查到的真相

CI 日志里 `[rtchild] t started` 之后再无任何 round 行 —— **一轮都没跑到
provider**。所以不是输出丢包，是轮次根本没启动起来（CI 的 2 核 runner +
race 插桩下启动更慢）。

原写法把两件事塞进同一个固定 5 秒窗口：

    waitFor(t, "开始输出", func() bool { return len(dev.snapshot()) >= 2 })

「输出已开始」是**前置条件**，「Stop 后输出冻结」才是被测行为。混在一起后，
超时只能报"没等到输出"，看不出到底是「轮次没启动」还是「输出没外发」。

## 改法（同 2026-10-24 TestStress_Nesting... 的先例：等状态，不等时间）

    waitForWithin(t, "轮次进入 ChatStream", 30s, p.callCount() >= 1)
    waitForWithin(t, "开始输出（chunk 到设备）", 30s, len(dev.snapshot()) >= 2)

两段分开等、各自 30 秒：超时能直接指认卡在哪一步。被测断言一字未改。
顺带把原来丢弃的 `PushRTInput` 返回值改成检查（同文件第 297 行本来就这么写）。

## 另一处已定位但**没修**

`TestResidualDropNotifiesSyncCaller`：本地整包 `-race` 8 轮偶发 1 次
（`应处置 1 条，实际 0`），CI 从未出现。

根因是 `waitSchedulerStopped()` 只等 `running == nil`，**不等调度循环退出** ——
cancel 之后循环仍有窗口把测试刚入队的任务取走。要修得给生产代码加
「循环已退出」信号，不是改测试能解决的。已记入 `docs/zh/future-plan.md` §5.0。

## 验证

    go vet ./internal/agent/core/                  ✓
    go test ./internal/agent/core/ -count=1        ✓
    go test -race ./internal/agent/core/ -count=1  ✓（连跑 3 轮）
    单测 -race -count=5                            ✓

internal/agent/core/rtchild_r3_test.go

@@ -262,13 +262,37 @@ func TestRTChild_OutputIsStreamed(t *testing.T) {
 // ── R5：打断即截断，且不重试 ──
 
 // TestRTChild_InterruptTruncatesOutput 钉住契约 2 的后半：被打断时就地截断。
+//
+// ## 前置条件为什么不用固定的 5 秒（2026-10-31 修偶发红）
+//
+// 本用例曾在 CI 的 -race 门里偶发失败，报「等待超时：开始输出」（5.00s），
+// 而本地 -race 连跑 6 轮全过。查 CI 日志：`[rtchild] t started` 之后
+// **一轮都没跑到 provider**，所以不是输出丢了，是轮次没启动。
+//
+// 它把「前置条件」和「被测行为」混在一个固定超时里了：被测的是
+// 「Stop 之后输出冻结」，而「输出已开始」只是 setup。setup 等不到时，
+// 报错看不出卡在哪一步（provider 没被调？还是输出没到设备？）。
+//
+// 改法同 2026-10-24 的 TestStress_Nesting...：**等状态**而不是等时间，
+// 并把两个阶段分开等——超时时能直接指认出卡在哪一步。
 func TestRTChild_InterruptTruncatesOutput(t *testing.T) {
 	p := &rtBlockingProvider{blockForever: true}
 	host, dev := newRTHost(t, p)
 
 	id := rtSpawn(t, host, "t")
-	host.PushRTInput(id, "一直说")
-	waitFor(t, "开始输出", func() bool { return len(dev.snapshot()) >= 2 })
+	if _, err := host.PushRTInput(id, "一直说"); err != nil {
+		t.Fatalf("投递输入: %v", err)
+	}
+
+	// 阶段 1：轮次真的进入了 LLM 调用。
+	// 这是其他一切的前提；过不去就说明轮次没启动（而不是输出没外发）。
+	waitForWithin(t, "轮次进入 ChatStream", 30*time.Second, func() bool {
+		return p.callCount() >= 1
+	})
+	// 阶段 2：provider 的 chunk 真的经 outputch 到了设备。
+	waitForWithin(t, "开始输出（chunk 到设备）", 30*time.Second, func() bool {
+		return len(dev.snapshot()) >= 2
+	})
 
 	if err := host.StopRTChild(id); err != nil {
 		t.Fatalf("停止: %v", err)