fix(agent): cancel 停不下调度循环 —— 队列非空时永远不看 ctx.Done

## 缺陷（真缺陷，不是测试问题）

`schedulerLoop` 只在"队列空"的分支里 select `ctx.Done()`：

	if kind == nextNone {
		select { ... case <-a.ctx.Done(): return }
	}

于是**只要队列里有任务，循环就永远不看 ctx.Done** —— 一直取、一直执行，
直到队列被取空才可能退出。

生产后果（`reclaim` / `destroy`）：销毁流程先回收残余任务、再销毁子。
而回收到销毁之间子仍在运行，继续把队列里的任务取走执行 —— 那些任务的
结果**永远无人认领**（子随即被销毁），且日志无痕迹：既不在"残余清单"里，
也没跑到出结果。带 ResponseCh 的同步调用方（cli/a2a）更糟：Stop 的
drainPendingInterrupts 给它补一个 "skipped"，用户看到"已跳过"，
而任务其实执行过。

## 修法

1. `schedulerLoop` 循环顶部（**取任务之前**）检查 ctx.Done。
2. 新增 `waitSchedulerStopped`：cancel 之后等 running 归零（上限 5s，
   超时如实记日志，不让控制面永久挂住）。
3. 新增 `FinishResident`：停止调度 → 回收残余 → 处置 → 收割记忆 → 销毁，
   **一步完成**，消除"取完到销毁"之间的窗口。`reclaim` / `destroy` 改走它。
4. 记忆收割抽成 `harvestResidentMemory`，供 FinishResident 的 onDestroy 复用
   （必须在 Destroy 之前 —— Destroy 会关掉 temp）。

## 判据（2 条，都做了"撤销修复必须变红"的验证）

 · TestSchedulerStopsTakingTasksAfterCancelWithNonEmptyQueue
   用阻塞 provider 把循环钉在 executeNewTask 里，此时塞 5 条进队列、
   cancel、放行。修复在位 ⇒ 5 条一条都不执行；撤销修复 ⇒ 取走 5 条。
   **实测撤销后报「仍取走了 5 条（剩 0/5）」，恢复后 10/10 绿。**
 · TestFinishResidentIsAtomic
   断言返回后子已从登记表移除（销毁确实在同一事务内完成）。

原 flaky 的 TestResidualKeepReturnsTasksToParent 与
TestResidualDropNotifiesSyncCaller 也修了：先 cancel + 等静止再入队，
得到确定的初始状态（它们验的是转交逻辑，不是子的生命周期）。30/30 绿。

## 我踩过的两条弯路（都写进判据注释了）

1. 加 `scheduler.freeze` 绕过。错在：调度器本来就有停止语义（ctx），
   再引入一个状态位会让"谁负责停"含糊，且忘了解除就永久僵住。已删。
2. 判据第一版写成「先 Start、再 cancel、然后入队」—— 那时队列是**空的**，
   循环正好走 nextNone 看到 ctx.Done 退出，于是**撤掉产品修复判据依然
   30/30 全绿**。是用户追问"凭什么说修好了"才发现这是假绿。
   必须造出"队列非空时 cancel"这个确切场景才测得到。

internal/agent/core/scheduler.go

@@ -1233,6 +1233,27 @@ func (a *Agent) schedulerLoop() {
 	}()
 
 	for {
+		// ★★ 退出检查必须在**取任务之前**（2026-10-18 修）。
+		//
+		// 原实现只在"队列空"分支里 select ctx.Done：
+		//
+		//	if kind == nextNone {
+		//		select { ... case <-a.ctx.Done(): return }
+		//	}
+		//
+		// 于是只要队列里有任务，循环就**永远不会看 ctx.Done** ——
+		// 一直取、一直执行，直到队列被取空才可能退出。
+		//
+		// 这就是"cancel 了却停不下来"的根因：销毁流程调 child.cancel()
+		// 之后，子仍把队列里的任务全取走执行，而那些任务的结果随销毁丢失。
+		// （之前我为此加了一个 freeze 标志绕过 —— 那是把一个状态机的
+		//   缺陷用另一个状态掩盖；正确的修法是在这里尊重 ctx。）
+		select {
+		case <-a.ctx.Done():
+			return
+		default:
+		}
+
 		a.pumpInbox()
 
 		t, f, kind := a.sched.nextRef()
@@ -1261,6 +1282,35 @@ func (a *Agent) schedulerLoop() {
 	}
 }
 
+// schedStopTimeout 是等调度器停下的上限。
+//
+// 不能无限等：子可能正跑一个长工具调用（几十秒）。超时就如实记日志并继续 ——
+// 宁可让那条正在执行的任务由 Stop 的 drainPendingInterrupts 补一个终态，
+// 也不要让父的控制面调用永久挂住。
+const schedStopTimeout = 5 * time.Second
+
+// waitSchedulerStopped 等调度循环不再持有运行中的任务。
+//
+// 前提：调用方已 cancel（关 ctx.Done）。调度循环在**下次取任务前**看到
+// ctx.Done 就退出（见 schedulerLoop 顶部的修复），于是 running 归零。
+//
+// 为什么不用一个 frozen 标志：调度器本来就有停止语义（ctx），
+// 再引入一个状态会让"谁负责停"含糊，且忘了解除就永久僵住。
+func (s *scheduler) waitSchedulerStopped(timeout time.Duration, name string) {
+	deadline := time.Now().Add(timeout)
+	for time.Now().Before(deadline) {
+		s.mu.Lock()
+		running := s.running
+		s.mu.Unlock()
+		if running == nil {
+			return
+		}
+		time.Sleep(10 * time.Millisecond)
+	}
+	log.Printf("[resident] %s 调度器 %s 内未停止（仍在执行任务），"+
+		"残余任务可能少回收一条（那条会由 Stop 补终态）", name, timeout)
+}
+
 // pumpInbox 把 channel 里**已就绪**的输入搬进就绪队列（非阻塞）。
 //
 // 为什么不直接边收边执行：先把已到达的输入收进队列，选择函数才有意义——