[Bug] provider 被删改后，旧会话 /compact 永久失败，且真错被吞进会话日志

[Prom1seCN]

改过 provider 架构（删除 / 改名 / 把多家 provider 收敛成一个）之后，在那之前已经开着的会话里 /compact 必然失败，界面只给一句笼统的

Compaction could not produce a useful summary. The attempt is recorded in the session log.

真正的错误只在会话日志里：no adapter registered for provider "xhx"（code NO_ADAPTER）。

两个具体缺陷：

1. 摘要目标的解析链不校验可用性。configured ?? latest ?? agentTarget —— latest 取的是「本会话最后一次已路由请求的 provider/model」，只看字段非空，不检查该 provider 是否还在注册表里。于是 latest 命中一个已经删掉的 provider，排在后面的 agentTarget（profile 的 agent-default-model，此时仍然可用）永远不会被用到。
2. 真错被丢弃。dsh-compaction-basic 抛的是 ManualCompactionError("summary", "manual compaction could not produce a smaller summary", { cause })，真错只在 cause 里；dsh-command-compact 的 expectedFailure 把 code summary 映射成一句固定文案，cause 不显示。用户除了翻会话日志没有任何入手点。

同一份 requestHeader() 还被 routedTarget() / reservedCompletionTokens() 使用（region.ts 的保留预算也读它）；自动压力压缩走 agent/pre-step 时会 catch 后只打一条 warn 继续，所以自动路径表现为静默不压缩，手动路径表现为报错但不说原因。

环境

• @deepseek-ai/dsh 0.2.0-rc.2，web profile，Linux
• 相关包：@deepseek-ai/dsh-compaction-basic、@deepseek-ai/dsh-command-compact
• provider 全部来自 profile 的 cordis.patch.yml（自定义路由，非内置目录）

复现步骤

1. 在 profile 的 patch 里定义若干自定义 provider（本例里按上游厂商分成多个 provider，其中一个 id 为 xhx）。
2. 打开一个会话，正常发一条消息 —— 此时该会话的路由头固定为 { provider: "xhx", model: "..." }。
3. 改 provider 架构：把按厂商拆的 provider 收敛成一个统一 provider（或直接删除 / 改名 xhx），重启 dsh。
4. 回到第 2 步那个会话，输入 /compact。

预期

压缩应当改用仍然可用的模型（profile 里 agent-default-model 就现成），或者至少把真错显示出来，例如：
no adapter registered for provider "xhx"。

实际

界面（command-compact 映射的 summary 文案）：

Compaction could not produce a useful summary. The attempt is recorded in the session log.

会话日志 $DSH_HOME/sessions/<槽>/session-<uuid>/session.v4.jsonl.zstd（zstd -dc 后）：

{"type":"compaction/end","seq":2966,"time":1792062239884,"data":{"compactionId":"abab20dc-...","sourceCommandId":"cmd-e5053688-1","turn":null,"error":"no adapter registered for provider \"xhx\""}}

同一会话此前还有一次普通回合因为同一个原因整个失败：

{"type":"turn/end","seq":2381,"data":{"turn":10,"reason":{"kind":"error","error":{"message":"no adapter registered for provider \"xhx\"","code":"NO_ADAPTER"}}}}

定位（0.2.0-rc.2 发布包）

@deepseek-ai/dsh-compaction-basic → summarizeWithLlm()：

const latest = agent.session.requestHeader()?.config;
const configured = config.summarizationProvider.length === 0 ? void 0 : {
    provider: config.summarizationProvider,
    model: config.summarizationModel
};
const agentTarget = agent.options.provider !== void 0 && ... ? {
    provider: agent.options.provider,
    model: agent.options.model
} : void 0;
const target = configured ?? latest ?? agentTarget;   // ← latest 未做可用性校验

同一个包里 routedTarget(session) 的注释也写明它取的是 "the exact provider/model durably routed for the latest request"。

@deepseek-ai/dsh-compaction-basic 第 527 行附近：

throw new ManualCompactionError("summary", "manual compaction could not produce a smaller summary", { cause: failure.error });

@deepseek-ai/dsh-command-compact → expectedFailure()：case "summary" 返回固定文案，未带 cause。

建议

1. summarizeWithLlm() 里对 latest 先做可用性判断（例如尝试 llm.resolveModelInfo(latest.provider, latest.model) 或在 provider 注册表里查适配器），不可用就退到 agentTarget；routedTarget() / reservedCompletionTokens() 读的是同一份 requestHeader()，同一类风险。
2. expectedFailure 的文案里带上 cause.message（或加 detail 字段），别让唯一线索只存在于会话日志文件里。

目前的规避办法

在那会话里先随便发一条普通消息（路由头刷新成当前 provider），再 /compact，即可正常压缩。
另可在 profile patch 的顶层把摘要模型钉死，与路由头无关：

- id: compaction-basic
  config:
    summarizationProvider: <provider>
    summarizationModel: <model>