背景
lib/providers/ 的请求装配链（runtime 配置 → 请求头装配 → 模型构造 → payload 中间件 → 流式分发 → 重试/failover）经多次迭代已经稳定可用，但缺少一层"整体行为锁定"的回归防线：现有 provider 测试逐字段断言单个行为（tool_choice、缓存断点、thinking 档位等），没有任何测试把一条协议"固定输入 → 完整 wire 请求体 / 完整传输头集"逐字段锁死。
这带来两个问题：
- 重构无判定基准：对装配链做行为等价重构（如适配器抽象、中间件管道调整）时，没有客观标准证明"改前改后发出的请求逐字节等价"，只能靠人工比对散落的单字段断言。
- 隐性回归难察觉：payload 中间件有 10 层，任何一层的顺序或条件变化都可能悄悄改变最终请求形态（比如给 text-only 请求带上 tool_choice 触发严格网关 400 的问题就属此类），单字段断言网covered 不到"整体形态漂移"。
提议
新增两组 golden 快照测试（纯测试，零生产代码改动）：
- 五协议 wire payload golden：anthropic-messages / openai-completions / openai-responses / google-generative-ai / deepseek-responses 固定输入下的完整请求体逐字段断言，走真实 pi-ai
stream() 与全部 payload 中间件，onPayload 截获后中断，零网络。
- 传输装配 golden：
prepareProviderRequest 完整输出（本地反代 URL、全量头集、base64 头覆盖包解码、鉴权头排除、full URL 模式、useSystemProxy 开关），以及 failover 场景下逐候选传输配置的独立性（主选走代理 + 备选直连时 x-liveagent-use-system-proxy 与凭据互不泄漏——多网络拓扑用户依赖的语义）。
快照写成显式对象字面量而非 .snapshot 文件，保证 diff 可读、杜绝无意 re-record。
验收标准
- 新增测试全部通过，且对五条协议与传输装配的关键形态均有整体锁定
- 不改动任何生产代码
- 现有测试套件结果不变
背景
lib/providers/的请求装配链（runtime 配置 → 请求头装配 → 模型构造 → payload 中间件 → 流式分发 → 重试/failover）经多次迭代已经稳定可用，但缺少一层"整体行为锁定"的回归防线：现有 provider 测试逐字段断言单个行为（tool_choice、缓存断点、thinking 档位等），没有任何测试把一条协议"固定输入 → 完整 wire 请求体 / 完整传输头集"逐字段锁死。这带来两个问题：
提议
新增两组 golden 快照测试（纯测试，零生产代码改动）：
stream()与全部 payload 中间件，onPayload截获后中断，零网络。prepareProviderRequest完整输出（本地反代 URL、全量头集、base64 头覆盖包解码、鉴权头排除、full URL 模式、useSystemProxy 开关），以及 failover 场景下逐候选传输配置的独立性（主选走代理 + 备选直连时x-liveagent-use-system-proxy与凭据互不泄漏——多网络拓扑用户依赖的语义）。快照写成显式对象字面量而非 .snapshot 文件，保证 diff 可读、杜绝无意 re-record。
验收标准