fix(lark): keep Inbox metadata probing off completed stop replies

[loopx-agent]

Completed group /stop replies repeat an identity probe just to rebuild Inbox display metadata, before the sender performs its own fresh provenance checks. Reuse the matching Inbox’s display name for this preparation step; both fresh outbound source checks remain mandatory. A renamed Bot refreshes metadata after the rejected preflight, and recovery after an already verified reply still rechecks grants before feedback.

The change stays in the existing Lark transport. Core stop targets, typed grant decisions, provider intents, readback, and other commands keep their owners. Tests cover changed identities and ancestry, revocation during delivery, cleanup after a crash, bad metadata, renaming, and original-topic idempotency.

Validation: focused native Chat tests and the risk-based premerge gate; an owned copy of the original completed-stop preparation path, using live read-only provider calls with every provider write denied, reduced the median from 7.68s to 6.05s (three samples per revision). This measures the preparation prefix; full installed stop timing, concurrent newer work, timely web finality and community release acceptance remain open.

[loopx-agent]

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

群聊成员在原话题发送停止指令后，需要尽快收到原助手的确定回执。 旧流程在回传校验前，为准备 Inbox 显示名称再次探测身份；新流程复用匹配的显示名称，发送边界仍重新核验来源和身份。 相同原请求的只读回传准备路径中位耗时由 7.68 秒降到 6.05 秒，原生停止目标和来源拒绝规则保持有效。 这次只降低已完成群停止的回传准备开销，不宣称完整停止回执、网页及时终态或社区发布已经达标。 完整安装后的停止时延、真正并发的新执行、网页及时终态仍由原社区验收继续验证。

按已接受的 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md（spec_revision da7d0b9979d2e7a2651cdc95230de70549278bfb）核对，而不是以缩短探测次数替代完整停止验收。

改动思路

显示名称属于 Lark 展示适配，授权属于既有 Core 和发送校验；在现有 owner 内调整准备顺序即可，不新增缓存授权或控制状态机。 本 PR 交付已完成群停止的回传准备优化和失败恢复，完整停止 SLA 继续沿既有社区验收推进。 最小改动是在既有展示准备中读取匹配名称；保持实际发送处的来源读取、两次新鲜身份观察和原 provider intent。没有增加授权缓存、新消息消费者、独立状态机或配置步骤。私聊、排队命令、其他控制及已验证回复后的清理继续走原绑定校验。

分支	当前提交的处理
原已完成群停止、回执待验证	名称仅作展示提示，发送仍核验原来源
授权或来源变化	阻止新的回复与反馈
名称过期或配置缺失	原服务重建元数据；改名可能多一次自动重试
回复已验证、清理未完成	重新核对当前授权后再清理

具体改动

精确 head：31876808f22ae8d26b27f012a2f248020b8f9a0f。_inbox 校验作用域格式，只从匹配 profile/chat 的旧配置复用显示名称，缺失、损坏或冲突时观察新元数据。reconcile_request 仅对 Core 已完成且目标固定、来源匹配、终态尚未验证的群停止省去外层展示探测；明确的发送身份不匹配只刷新元数据，下一次正常 reconcile 继续。_source_message、_deliver 与通用 Inbox 写入、读回 owner 保持原权威。

规格行：original-source 已实现，新名称不能替代身份、群来源、发送人、根/父/线程及根 @ 校验；frozen-stop-target 已实现，原生 Session/Turn 冻结与重放目标没有变化；intent-recovery 已实现，未知写入继续按原 intent 读回，已验证回复后的撤权阻止反馈；installed-live-exits 保留待验收，准备路径的测量不能代表完整停止、真实并发或网页及时性。

两版通过同一组 14 个原话题正反例，实际调用 per-request reconcile、临时 File 原生存储和 typed Core，飞书与本地模型宿主为合成 fixture。故意取消发送来源 guard 后，App、撤权、发送人、chat、root、parent、thread 七例失败，说明拒绝断言能识别权限退化。最终 head 的相关 Chat、绑定、协同套件 214 项通过，风险 canary 的 5 个直接检查与 10 个选定检查通过；当前 Goal 不查询、不轮询、不等待 CI，CQR 当前关闭。

对主干的风险

没有阻塞发现。主要风险是误把展示提示当成授权，或在终态已验证的恢复路径绕过当前 grant。本提交分别通过发送来源 guard 和 verified-terminal 排除条件保留边界，回归覆盖在等待中改变来源、撤权后的清理、配置损坏和幂等原话题回复。两版原请求/来源的只读准备实验保持相同输入和保护状态，所有 provider 写入均被拒绝；它不能证明线上完整回执 SLA、原生子进程取消或浏览器及时终态。改名可能多一次自动 reconcile，这是无需人工介入的有界恢复代价，不能宣传为所有条件下都加速。

我的整体评价

批准这一可独立回退的缓解阶段，整体问题仍为 justified increment。显示名称属于 Lark 展示适配，授权属于既有 Core 和发送校验；在现有 owner 内调整准备顺序即可，不新增缓存授权或控制状态机。 本 PR 交付已完成群停止的回传准备优化和失败恢复，完整停止 SLA 继续沿既有社区验收推进。 长程继续与原始回执恢复保持；普通已完成群停止的准备等待减少，但 Bot 改名保留一次自动重试的权衡。新增生产代码净增 35 行，复用现有 owner 和原 journal，无协议迁移；测试保护真实来源与恢复边界，不以 PR 数或测试数证明完整目标达成。内部布尔参数仍是本地展示辅助，没有扩展共享语义词汇；后续应回到既有安装后停止/并发/网页验收，不另造控制框架。

English verdict: APPROVE - 3187680; remove the redundant display-metadata probe while retaining fresh source authority and verified-reply cleanup. 214 tests, paired 14-case journeys and 15 premerge checks pass. Full installed stop/web timing remains open.