[Bug][blockOps] The summary stored by acp_rewrite is not subject to compress's length min/max bounds or net-shrinkage ch | [Bug][blockOps] acp_rewrite 存进去的摘要不受 compress 的长度上下限和净收缩检查约束；blockId 不接受数字 #6319

环境

• billion-context master，c26c31ace。相关工具来自 Request two capabilities: compressed block "retirement" and summary "external rewrite". | 请求两个能力：压缩块「退役」与摘要「外部重写」 #5765 / PR [PR] feat: compress-block retirement (acp_retire/acp_restore) + external summary rewrite (acp_rewrite) + export ledger #5774（压缩块生命周期工具，compress.blockOps，默认关闭），只影响开了 compress.blockOps.enabled 的会话。
• 宿主侧问题，不涉及 kernel/**。

问题

acp_rewrite 替换的是块里存的摘要，而这份摘要每个请求都会随常驻视图发出去。compress 对写进这里的摘要有把关；acp_rewrite 只查「非空」和「与原来不同」，所以同一个块上 compress 会拒收的摘要，acp_rewrite 照样存进去。

默认配置（compress.maxSummaryLength 20000，minSummaryLength 50），折叠一段约 6000 字符的范围：

工具说明写的是「replace … with shorter text you supply」，但没有任何检查让调用遵守这一点。一个块被改写成 25000 字符后，之后每个请求的开销都比它折叠掉的那些消息还大。

另一处：acp_retire / acp_restore 通过 collectBlockIds 接受数字形式的 blockId: 5，acp_rewrite 却只认字符串：{ blockId: 1, summary } 回的是 provide { blockId, summary } or items: …，就像什么都没传；items: [{ blockId: 1, summary }] 也一样。

建议的修法

在宿主侧 src/acp-block-ops.ts 调内核之前，按解析后配置里的 compress.minSummaryLength / compress.maxSummaryLength 检查改写后的文字（含义、回执措辞与 compress 一致），再加一道净收缩检查（摘要不比块折叠掉的内容小就拒收）；同时让 blockId 在单条形式和 items 里都接受非负整数。修复在 #6315。