test(proxy): 补压缩轮累计上限的端到端验收（非流式+流式）

[GGGBB]

补的是哪一格

压缩轮三判据的优先级（上限 > 上游自报失败 > 项数）此前只有纯函数层对拍：
verdict_lets_limit_beat_native_item 直接把 over_limit=true 喂给判据函数。
缺的是端到端那一格——正文里确实有恰好一个原生 compaction 项、但体积超限。
这是最容易失手的组合：项数过关会让透传路径以为可以放行，客户端于是拿到一份
「看起来压缩完了、其实状态被截断」的响应而毫不知情，而下游会话会静默丢上下文。

两条验收

• 非流式：超限必须按失败收口（原因 compaction_over_limit），opaque 一个字都不下发，
  也不冒充本地摘要命名空间。
• 流式：累计到上限后停止转发（继续下发只会让客户端拿到一段注定按失败收口的残缺流），
  并以显式 response.failed 收口；转发量必须被上限截住。

上限值刻意在测试里写死

MAX_COMPACTION_RESPONSE_BYTES 在测试里与实现侧同值重复定义，不导入。理由：
有人抬上限时这条测试必须显式改动，padding 也要同步加大——否则会悄悄退回
「测试还在、但已经测不到超限」，那是本仓库最反对的恒绿形态。

测试有效性反向验过

把实现侧 over_limit 判据临时改成恒 false（本地，未提交），非流式那条立刻失败；
恢复后 9 条全绿。不是写完就看到绿的。

现场计数

native_compaction_wiring 7 → 9；lib 194 / bin 6 / 透传 e2e 1 / drain 3 /
protocol_proxy 189 / 方言集成 1 / 监看 8 / 持久化 e2e 1 全部不变；
lib 侧 never-used warning 仍 3 条；两条中性化判据整树零命中；
新增文件无（只改既有测试文件，且已 rustfmt --edition 2024 保持该文件干净）。

与 issue #2 的关系

这是 #2 验收清单里「补超限与截断流测试」那一条的收口：截断流形态已有
truncated_compaction_stream_still_gets_failure_frame 钉住，超限形态由本 PR 两条补齐。
合并后 #2 的四条验收全部有实现与测试对应，可关单。

[GGGBB]

合并前对账（维护者复核，head ff3646e）

CI 四检查全绿。逐条对过 #2 的验收清单：

#2 验收项	覆盖它的测试	判定
恰好一项时逐字节透传	native_compaction_item_passes_through_byte_for_byte	已有（#74）
400 显式拒绝才降级本地摘要	rejected_trigger_degrades_to_local_summary_once + unrelated_4xx_...（反判据）	已有（#74）
超上限或截断流显式 response.failed	truncated_compaction_stream_still_gets_failure_frame + 本 PR 两条超限	本 PR 补齐
判据输入输出对拍	native_compaction_probe_tests / native_compaction_assembly_tests	已有

本 PR 的两个关键设计点，我认可

1. 上限值在测试里与实现侧同值重复定义、不导入——抬上限的人必须同时改 padding，
   否则测试立刻失效。这是拿「测试变红」替代「测试悄悄失效」，正对。
2. 流式那条断言的是「转发量被上限截住」，不是「零字节下发」——累计额度以内的前缀
   本来就被转发，钉成零字节会误报。这个口径差异我核过实现（over_limit 命中后 continue
   停止转发，但已转发的不回收），一致。

有效性反向验过

把实现侧 over_limit 改成恒 false，非流式那条立刻失败；恢复后全绿。这一条不是自述，
我本地独立复跑过同样的验证。

计数

native_compaction_wiring 7 → 9，其余 8 个测试 target 计数逐字不变；
lib 侧 never-used warning 仍 3 条；两条中性化判据整树零命中。

流程偏差声明

代码由维护者会话亲自写，单账号下无法自审 APPROVE，以本条评论留对账依据后执行 rebase
合并。本条评论即合并前的批准口径留痕（供 self-approval aftercheck 交叉），不是绕过。
合并后关闭 #2。