fix(opencode): 采纳客户端真实会话 id + 超窗消息不再被限流措辞封杀

两处都源于同一次排查：pi 到底有没有带会话标识、超窗为什么触发不了压缩。

## 1) 客户端会话 id：pi 一直在发，只是被配置关掉了

之前结论是「通用客户端不发会话 id」——只对了一半。pi 有会话 id，且能发：
pi-ai 的 createClient 在 compat.sendSessionAffinityHeaders 为真时，会把
平台会话 id（uuidv7，整个会话恒定）放到 x-session-affinity /
x-client-request-id / session_id 上。该开关默认 false，而 llmsproxy 的
provider 配置里没开，所以此前一直收不到。

现在网关按优先级采纳：x-session-affinity → x-session-id → session_id →
body 的 prompt_cache_key，并把值经 types.ChatRequest.ClientSession 传到
适配器 meta.client_session。适配器的会号种子优先级变为：
客户端会话 id > 首条 user 消息指纹 > 按源固定。

刻意不采纳 x-client-request-id：名字含 request，部分客户端每请求都换，
拿它当会话会让上游前缀缓存永不命中（pi 总会同时发 x-session-affinity，够用）。

实测：抓 127.0.0.1:8081 的真实 pi 请求，配置打开后收到
x-session-affinity = session_id = x-client-request-id = <子会话 uuid>。
上游缓存确为会话级隔离（同前缀、不同会号：A 冷→命中，B 首次仍为 0），
两个不同 header 值互不命中，反证网关确实采纳了客户端会话 id。

## 2) 超窗消息必须「干净」，否则被同链的限流措辞反向封杀

pi 的 isContextOverflow 先查 NON_OVERFLOW_PATTERNS（/rate limit/、
/too many requests/、Bedrock 前缀），命中就直接判为「非超窗」——**即使
消息里已经有 context_length_exceeded**，pi 也不会压缩重试。

而 AUTO 链的失败消息天生是多 tier 原因的拼接，超窗 tier（gozen 400
maximum context length）常与配额/限流 tier（429 token plan exhausted、
cooling、no free slot）同时出现。此前把 tier 明细原样拼在归一化标记后面，
等于让一条限流 tier 的措辞反过来封杀超窗识别。

现在超窗走独立的干净消息：
  context_length_exceeded: context window is full; reduce the length of
  the messages (gozen/deepseek-v4.1-flash)
只留超窗措辞 + 超窗源名，不带任何其它 tier 的文本。

测试：TestOverflowMessageSurvivesRateLimitedSiblingTier 用 pi 的完整判定
顺序（先 NON_OVERFLOW 后 OVERFLOW）断言同链限流 tier 不再封杀超窗识别；
TestClientSessionFromRequestHeaders / TestClientRequestIDIsNotUsedAsSession /
TestOpenCodePrefersClientSessionID 覆盖会话采纳与优先级。

internal/lua/adapters/opencodezen.lua

@@ -63,6 +63,33 @@ local function conversation_fingerprint(body)
     return ""
 end
 
+-- session_seed 决定上游会话号（x-opencode-session 的种子）。
+--
+-- 优先级：
+--   1) 客户端自带的会话标识（meta.client_session）——pi 等在开启
+--      compat.sendSessionAffinityHeaders 后会发 x-session-affinity，
+--      这是平台真实的会话 id，整个会话恒定且天然按会话隔离。
+--   2) 退路：历史里**第一条 user 消息**做会话指纹。
+--   3) 再退：只按源固定（连 user 消息都没有时）。
+--
+-- 为什么需要 2/3：通用 OpenAI 客户端默认**根本不发**会话标识 —— 实测抓包
+-- （tcpdump 抓 127.0.0.1:8081 真实 agent 请求）确认 body 里没有
+-- user / session_id / conversation_id / metadata，请求头也只有
+-- X-Stainless-*（OpenAI JS SDK）与 User-Agent。opencode 原生客户端那套
+-- x-opencode-session 是它自己的概念，通用客户端无从转发。
+--
+-- 为什么必须稳定：上游前缀缓存是**会话级**的。会话号每请求一变，
+-- 缓存永不命中（实测：固定会号第 2 次命中 5888，每请求换会号则恒为 0）。
+local function session_seed(meta)
+    local src = (meta.source and meta.source.name) or ""
+    local base = "session|llmsproxy|" .. src
+    local cs = meta.client_session
+    if type(cs) == "string" and cs ~= "" then
+        return base .. "|client|" .. cs
+    end
+    return base .. "|" .. conversation_fingerprint(meta.body)
+end
+
 function adapter.build_headers(meta)
     local ts = tostring(meta.timestamp or "")
     local src = (meta.source and meta.source.name) or ""
@@ -77,7 +104,7 @@ function adapter.build_headers(meta)
         --   每请求换 session -> 永远 0 命中
         -- 原先用 meta.timestamp 派生，等于每请求都是新会话，缓存永远无效，
         -- 上游也无法做会话亲和路由。
-        ["x-opencode-session"] = rand_id("ses_", "session|llmsproxy|" .. src .. "|" .. conversation_fingerprint(meta.body)),
+        ["x-opencode-session"] = rand_id("ses_", session_seed(meta)),
         -- request id 仍每请求唯一（它只是请求标识，不参与缓存键）
         ["x-opencode-request"] = rand_id("msg_", "request|" .. ts .. "|" .. tostring(meta.body or "")),
     }