fix: detect chained bili instances (hop marker) — double processing corrupts session state

[ranxianglei]

Model: glm-5.3

双 bili 串联无检测：三重处理导致状态搅乱（issue #292 主因）

证据（来自 issue 附带日志 bili (8).log）

13:21:22.139Z forward POST → http://127.0.0.1:50157/bili/https://api.anthropic.com/v1/messages?beta=true

请求路径：claude → 8787（MITM，outer session 366af3e19c251c72，窗口 200000）→ 50157（prefix 实例）→ 8787（再次拦截，inner session 4b93227797589299，窗口 1000000）→ Anthropic。同一个 claude-fable-5、同一个 x-claude-code-session-id，两层各自跑 processTurn + 压缩循环 + 独立 kernel 状态：

• 模型调 compress 只有最内层（inner）折叠；outer 状态从不折叠 → 外层持续全量历史（「上下文涨」）
• inner 折叠后转发的 body 与 outer/claude 保留的全量历史不一致，跨层 ref 映射错位 → inner 状态被搅乱后 filter 几乎隐藏全部消息（13:28:17 round 1 input=2 cached=0，同时刻仍有真实 Bash 调用被裁决——证明主回合近乎空 body 转发）
• 已用纯 kernel 复现排除 kernel 嫌疑：compress m00003–m00041 后再 compress m00005–m00044，kernel 安全处理（只为未覆盖增量建块、双摘要注入、无塌缩）。塌缩在 bili 状态层，根因是双重处理。

修复要求

1. bili 向上游转发请求时加自有标记头（如 x-bili-hop: <instance-uuid>）
2. 收到入站请求若已带 x-bili-hop（非本实例）→ 判定为 bili→bili 串联：
   • 跳过全部处理（不注入工具/标签、不跑 acp-loop、不建 session 状态），原样透传
   • 打 [warn] 醒目日志：检测到下游 bili 串联，建议只保留一个实例
3. e2e 测试：两个代理实例串联（A forward → B），断言 B 记录告警且请求体未被 B 二次改写（无 acp 标签注入、无工具注入）

验收

• 串联拓扑下单层处理，压缩正常折叠
• 单实例正常使用完全不受影响（claude 回传带 acp 标签的消息不误报——标记头只在 bili 自己的转发中出现，客户端不会带）

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] 收到 #300。开始实现：出站转发加 x-bili-hop 标记头，入站检测到非本实例的 hop 头则原样透传 + [warn] 日志，并补 A→B 串联 e2e 测试。完成后贴 PR 链接。

[ranxianglei]

🤖 ework agent · vllm-qwen/qwen3.8-27b

[bot] 已修复，PR: #304

根因确认：与你的分析一致——双重处理（两层各自跑 processTurn + 压缩循环 + 独立 kernel 状态）导致 outer 从不折叠、inner 折叠后 body 与 outer 全量历史不一致、跨层 ref 映射错位。kernel 本身无嫌疑（你已用纯 kernel 复现排除）。

修复方案（src/server.ts）：

1. 出站标记：每个 server 实例生成 instanceId = randomUUID()。凡本实例真正处理过的请求，转发时打 x-bili-hop: <instanceId> 头——覆盖主转发、preflight 摘要调用、compress-loop 调用（后两者复用 buildForwardTarget 的 headers）。
   • 关键点：passthrough 转发不打标记（不声称处理过），所以"哑代理 bili 前置 + 处理型 bili 后置"的拓扑不受影响；入站已有的标记会原样向下游传播。
2. 入站检测（handle()）：入站请求若已带 x-bili-hop → 判定上游 bili 已处理 → 跳过全部处理（不注入工具/标签、不跑 acp-loop、不建 session 状态），原样透传，并打醒目 [warn]：
   • 外部实例：[chain] inbound request carries x-bili-hop from another bili instance (<id>) — bili→bili chain detected. ... keep only one bili instance in the chain.
   • 自环（upstream 指回自己）：单独提示检查配置。

为何单实例不误报：客户端从不发送 x-bili-hop（它只出现在 bili 自己的转发里）。claude 回传带 acp 标签的消息不带该头，正常回合完全不受影响。

e2e 测试（新增 tests/e2e-bili-chain.test.ts，2 个用例）：

1. B 单独 + 外部标记：请求体到达 LLM 逐字节一致（无工具注入、无 acp 标签、无重序列化），恰好一条 [chain] 告警且点名上游标记，标记原样透传未被 B 改写。
2. 完整 A→B 串联：单层处理（A 打标记、B 告警+透传），LLM 恰好收到 1 次请求，LLM 处的标记是 A 的（非 B 重打）。

Pre-flight：

• npm run typecheck ✅ 无错误
• npm test ✅ 693 通过（691 既有 + 2 新增），0 失败
• npm run build ✅ 成功

无依赖变更，package.json version 未动（内容分支）。merge 后 CI 会自动发布。