feat(resident): 分诊助手定位 + 残余任务由父显式决定

用户澄清（重要定性）：这不是「内核替父决定」，而是**及时反馈** ——
主 agent 忙时不该让用户干等十几分钟。子 agent 是**分诊助手**：
简单的直接处理并回复，需要主 agent 的立刻回「忙碌中，请稍候」、不勉强作答。

三处补齐：

1. 分诊助手的职责提示词（之前完全没给 ⇒ 子不知道自己为什么存在）：
   两条路（直接办 / 报忙碌）、拿不准时报忙碌、必须 output_send 到原通道。
2. 驻留子继承父的 SystemPrompt（之前没传 ⇒ 子只用一句兜底文案，
   拿不到「异步通道必须显式 output_send，否则回复被静默丢弃」这条铁律。
   webui 这类同步通道能回是因为走 ResponseCh，掩盖了这个缺陷）。
3. 残余任务由父显式决定（用户要求）：reclaim/destroy 时子手头未处理的消息
   不再由内核悄悄处置 —— 内核只负责列清楚，父用 residual=keep/drop 决定。
   之前 pendingEvents 只收带 ResponseCh 的，异步（qq）残余任务完全不在内，
   被销毁时静默消失、用户零反馈且日志无痕。

配套：
- scheduler.takeAllPendingEvents：取走全部未执行事件（不筛通道）
- ApplyResidual(keep|drop)：keep 转回父队列（保留 ResponseCh），
  drop 逐条记日志 + 给同步调用方补终态（否则 cli/a2a 永久挂起）
- 状态面暴露 offload_owned，让父分清「我建的子」与「内核临时拉的助手」
- 工具 schema 加 residual 参数并说明 drop 的代价

这也是用户观察到的「机制很自然」的落点：分诊助手就在同一张登记表里，
父能 inspect/send/compress/reclaim/destroy，控制面 6 动作按 id 生效不区分来源。

测试 +7（残余 keep 转回且保留 ResponseCh / drop 通知同步调用方 /
空残余如实报告 / 分诊提示词 / 继承 SystemPrompt），
其中 drop 那条已实测「对着静默丢弃的旧实现会失败」。全套绿。

internal/sdk/status.go

@@ -122,6 +122,13 @@ type ResidentStatus struct {
 	InputChTable   int      `json:"input_ch_table"`
 	CreatedAt      string   `json:"created_at,omitempty"`
 
+	// OffloadOwned 标记这是**内核为承接积压而拉起**的临时助手（见 core/offload.go）。
+	//
+	// 为什么要暴露给状态面/工具面：父的模型需要分清"我建的子"与
+	// "内核临时拉的分诊助手" —— 前者该按需回收，后者在空闲、无积压时
+	// 可以安全回收，而**正忙时不该回收**（会让用户的消息再次无声丢失）。
+	OffloadOwned bool `json:"offload_owned,omitempty"`
+
 	// 以下四项是该驻留子**自己的**调度器积压摘要，用于 per-agent 负载环形图。
 	//
 	// 根 agent 的积压看 KernelStatus.Scheduler；每个驻留子是独立 agent、