群历史检索后的按轮次污染升级:与权限档正交的确认通道

从 #2080 review 外推。

**问题**:owner 私聊里调用 `cindy_group_history.search` 会把群成员可控内容拉回模型上下文。#2080 已给结果套上不可信数据栅栏(与 group window 同款边界),但栅栏是**软**约束;精确的硬约束应当是「本轮一旦真的拉回过不可信群历史,后续 destructive / opaque-write / 嵌套分派调用强制走 owner 确认」。

**为什么不能直接用 turnPermissionPolicy**:`packages/maker-core/src/agents/claude-code/index.ts:4137-4148`(codex `index.ts:8755` 同构)的 `validateSendOptions` 规定,会话权限档为 `acceptEdits` / `bypassPermissions` 时只要带 `turnPermissionPolicy` 就抛 `TurnPermissionPolicyUnsupportedError`,turn 直接报错不跑。群 guest 轮次接受这个 fail-closed 是刻意设计,但 owner 私聊普遍是全权档 —— 给 DM 挂策略等于把私聊全线打死,回归比它要防的注入更严重(`im/telegram/adapter.ts:96-102` 有这条权衡的现存记录)。

**要做的**:一条与权限档正交的逐轮升级通道。要点:
1. 污染标记按 (sessionId, sessionInstanceId) 记账,由检索工具在**真正返回命中**时置位(空结果不污染),随租约一起释放;
2. 升级后的确认判据复用 `channelForceConfirmToolCall`(已覆盖 Claude call_tool / Codex MCP elicitation / Pi 桥接与二级分派的内层解包),不得只挡直接工具名;
3. 确认卡只认 owner 点击;确认通道自身不可用时 fail closed(拒绝执行,而不是放行);
4. 全权档会话下必须仍能工作 —— 这正是现有 turnPermissionPolicy 做不到的那一格。

**验收**:owner DM 先检索其它个人 Telegram lane、再尝试 Bash/delete/permissions 或嵌套 dispatch,必须命中确认;未检索过的普通 DM 轮次零行为变化(不弹卡、不降速);全权档会话不因此报错。

关联:#2080(栅栏已落地)、#1855。

Start with validateSendOptions in packages/maker-core/src/agents/claude-code/index.ts:4137-4148 and the corresponding Codex entry at index.ts:8755, then read the tradeoff recorded in im/telegram/adapter.ts:96-102. Trace channelForceConfirmToolCall and the retrieval tool’s hit path, including lease cleanup. Done means only contaminated owner-DM turns require owner confirmation, confirmation failure rejects execution, and untouched or full-permission turns behave unchanged.

Written by the indexing model from the issue text.