fix(opencodego): inject empty reasoning_content on tool-calling turns

v1.5.4 stopped stripping reasoning_content, which fixes clients that send
it — but most agent clients (pi included) never store or replay their
reasoning, keeping only the tool call. OpenCode Go validates the field on
any assistant turn that carries tool_calls and rejects the whole request:

  400 invalid_request_error: The `reasoning_content` in the thinking mode
  must be passed back to the API.

Verified against the live endpoint that an EMPTY string satisfies the
check, so the adapter now fills in "" when a tool-calling assistant turn
has no reasoning_content. Nothing is fabricated: the reasoning shown to
the client is still exactly what the upstream returned for that turn.

Measured: with a tool_call + tool_result history and no reasoning_content,
all 25 configured Go models returned 400 before and all 25 answer
correctly now.

Test: TestOpenCodeGoVsZenReasoning also pins that a plain assistant turn
(no tool calls) must NOT gain the field.

internal/lua/adapters/opencodego.lua

@@ -79,6 +79,17 @@ function adapter.transform_request(raw_body)
             -- 上游直接 400（"The `reasoning_content` in the thinking mode must
             -- be passed back to the API"），agent 的每一轮都会失败。
             -- 注意：与 opencodezen.lua 的行为**相反**，不要在这里剥。
+            --
+            -- 但绝大多数客户端（pi 等）根本不保存也不回传 reasoning，只保留
+            -- 工具调用本身。上游只在“带 tool_calls 的助手轮”上校验这个字段，
+            -- 实测**空串即可通过校验**，所以缺省时补空串：既满足上游的
+            -- 一致性要求，又不伪造任何推理内容（用户看到的 reasoning 仍然是
+            -- 上游本轮真实返回的）。
+            if msg.role == "assistant"
+                and type(msg.tool_calls) == "table" and #msg.tool_calls > 0
+                and msg.reasoning_content == nil then
+                msg.reasoning_content = ""
+            end
             local drop = false
             if type(msg.content) == "table" then
                 local parts = {}