fix(agent-core-v2): strip media and retry once on unclassified client 400s - #4864

Requirement or Bug

Resolve #4863

一次正常的读图操作（ReadMediaFile 读取一张很小的 PNG）之后，服务端返回了通用 400 Invalid request Error。由于错误未被识别为与媒体相关，会话不做任何恢复：该步直接失败，之后的重试、后续 turn、甚至手动触发的 full compaction 都把同一条图片消息原样重发、以同样的 400 失败，整个会话不可恢复直到崩溃。本 PR 让这类"携带媒体的请求被未分类客户端 400 拒绝"的场景可以自动剥离媒体重试一次，会话得以继续。

注：按 CONTRIBUTING 约定，本 PR 链接的 issue 尚待维护者 /approve 评论批准。

Bug Reproduction Steps

See linked issue（issue 中包含 debug 包时间线、三次 400 的 requestId 与 wire.jsonl 证据）。

Root Cause

这是根因修复（针对客户端恢复缺口；服务端为何返回通用 400 属于网关行为，客户端无法依赖其消息内容）。

时序如下：

1. ReadMediaFile 工具结果以 kimi-file:// 图片消息进入上下文；请求时 AgentMediaResolverService.resolve 将其解析为 data URL / 上传引用，这一步正常。
2. 网关返回通用 400 Invalid request Error。toLlmStatusErrorMessage（src/human/llm/protocol/rules/status.ts）中它不匹配 image_format、request_structure 等任何消息模式，被归为 kind: 'status'。
3. 媒体恢复策略 createMediaDegradeRecovery（src/human/llm/builtin/policy/media-degrade.ts）只对 request_too_large 和 image_format（含 unsupported media type for base64 image / invalid data url for image 消息模式）提出剥离/降级，通用 400 不在范围内，于是当步失败、无剥离重试。
4. fix(agent-core-v2): keep media recovery across turns and compaction #4413 让恢复快照跨 turn 与 compaction 持续，但前提是先产生过恢复记录；本次一次都没有，后续 turn 与 full_compaction（droppedCount=0）把同一媒体原样重发 → 同样 400 → 会话死亡。

Code Changes

在恢复策略中新增一个分支：未分类的客户端 400（kind: 'status'、statusCode === 400、非 retryable）且当前请求携带媒体部件时，走与 image-format 拒绝相同的剥离重试路径，但标记为专用 action stripped-client-error。

 propose({ error, request, appliedRecoveries })
   imageFormat = ...（不变）
+  mediaClientError = error.kind === 'status'
+    && error.statusCode === 400
+    && !error.retryable
+    && countMediaParts(request.content.messages) > 0
-  if (error.kind !== 'request_too_large' && !imageFormat) return undefined
+  if (error.kind !== 'request_too_large' && !imageFormat && !mediaClientError) return undefined
   ...
-  return stripEntry(messages, appliedRecoveries, replacement)
+  strip = stripEntry(...)
+  if (strip !== undefined && mediaClientError)
+    return { ...strip, action: 'stripped-client-error' }   // 不持久化
+  return strip

同时两处配套：

• core/request.ts 的恢复存储在写入时按 action 过滤：stripped-client-error 永远不会被持久化到跨请求恢复存储（在 store 边界过滤，而不是只在事件处跳过——否则后续任意 media-degrade 事件都会把整个 ledger 连同它一起写入）。
• 剥离记账 isStrippedRecord 同时识别 stripped 与 stripped-client-error，避免混合错误序列（通用 400 剥离后重试又遇 413）产生无意义的无重写恢复事件。

因果说明：

• 为什么不持久化通用 400 的剥离：通用 400 不一定由媒体引起。若误剥离被持久化，无关故障恢复后，后续请求会在没有警告的情况下永久丢失有效图片。不持久化后，误判的最大代价是当次请求多一次必然同样失败的重试，错误照常上浮；任何后续请求都不受影响。这是从设计上消除误伤，而不是逐场景加守卫。
• 代价：原始崩溃场景中，只要图片还在历史里，后续每个 step 的首次请求仍会得到一次通用 400，再剥离重试成功（每次多一个失败请求和一条 warning）。若维护者希望成功后持久化（省掉重复 400），需要"重试成功才持久化"的 tentative 机制，复杂度高得多，本 PR 刻意不做。
• 为什么排除 retryable 错误：可重试的 400 应保留媒体走正常 backoff，剥离会让后续 backoff 请求永久丢失图片。
• 为什么不会循环：剥离后媒体部件消失，countMediaParts === 0 不再命中新分支，stripEntry 也因无媒体且已剥离返回 undefined，错误照常上浮。
• 既有行为：413 / image-format 的剥离/降级及其跨 turn/compaction 持久化（fix(agent-core-v2): keep media recovery across turns and compaction #4413）完全不变；既有测试 does not resend for an unrelated 400（无媒体）语义不变。

Behavior Changes and Affected Users

受影响模块与测试覆盖：

• src/human/llm/builtin/policy/media-degrade.ts（新分支与剥离记账）、src/agent/loop/core/request.ts（存储边界 action 过滤）— 由 test/agent/llmRequester/llmRequesterService.test.ts 新增七个用例覆盖：
  • 通用 400 + 携带媒体 → 剥离后重试并成功（calls.value === 2，媒体数 [1, 0]）；
  • 通用 400 + 无媒体 → 不重试（钉住旧行为）；
  • 剥离后重试仍失败 → 原错误上浮且仅重试一次；
  • retryable 的 400 + 携带媒体 → 不剥离，媒体原样保留；
  • 剥离成功后的后续请求 → 不继承剥离，媒体照常发送（[1, 0, 1]）；
  • 剥离重试失败后的后续请求 → 同样不继承（[1, 0, 1]）；
  • 通用 400 剥离后重试遇 413（混合错误序列）→ 不持久化、无 no-op 恢复事件，后续请求媒体仍在。
  • 已验证：回退源码改动后新用例如期失败（测试非空转）。
• 验证范围：llmRequesterService.test.ts 75/75 通过；modelRequester.test.ts 14/14 通过；包级 typecheck 通过。sessionMediaStore.test.ts 与 fullCompaction.test.ts 各有 4/1 个失败，已在干净基线上复现确认为 Windows 环境既有失败，与本改动无关。
• 另经独立代码审查一轮：发现的"后续 media-degrade 事件会把整个 ledger 连同通用剥离一起持久化"的漏洞已通过存储边界过滤 + 剥离记账修复并回归测试覆盖，复查无遗留问题。

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue (external PRs: issue must have a maintainer's /approve).
• I have added tests that prove my feature works.
• The behavior-change table above is complete, and every removed behavior or flipped default is named in the changeset and either has an escape hatch or was explicitly approved by a maintainer in this PR.
• Ran gen-changesets skill, or this PR needs no changeset.
• Ran gen-docs skill, or this PR needs no doc update.