fix(lua): 补齐 6 个适配器的流式 tool_calls 支持

体检判据（TestAllBundledAdaptersStreamToolCallStatus）报出的三类问题，
本提交解决其中两类；第三类（gemini）未动，原因见下。

## ① OpenAI 兼容族：github / groq / mistral（3 个）

它们的 transform_stream_chunk 与修复前的 deepseek **逐字相同** ——
只透 content/done，tool_calls 处理只存在于 transform_response（非流式）。

后果与 deepseek 相同：流式模式下工具调用全部丢失，模型调不动任何工具，
且**没有任何报错**。生产当前未启用这三个源，但按预设配置的用户会踩到。

照 deepseek 的修法补上（含 reasoning_content 透传）。

## ② 嵌套形态 + 键名错：server / kimicode / anthropic / ollama（4 个）

这四个**有** tool_calls 处理，但发的是：

    { index = N, id = ..., ["function"] = { name = ..., arguments = ... } }

而 homed 的 `agentAPI.ToolCall` 是**扁平**结构，json tag 为：

    id / type / name / arguments / raw_arguments / stream_index

两处都是**静默**失效（Go 侧按 json tag 反序列化，取不到就是零值，无报错）：
- **嵌套** `["function"]` ⇒ `name` / `raw_arguments` 取零值
  ⇒ flush 时判「无 name」丢弃，或参数为空
- **键名 `index`** ⇒ `StreamIndex` 取零值
  ⇒ 多个分片并到同一个桶，argsRaw 混拼 ⇒ 每个工具报「参数不是合法 JSON」
  而**一个都没真跑**

已逐项对齐为扁平 + `stream_index`。协议差异都保留：
- anthropic：`content_block_start` / `input_json_delta`，续传片 name 留空
  （内核按 stream_index 累积，补齐 name 后才 flush）
- ollama：tool_calls **整条一次发完**（不分片），故 stream_index 取数组下标

## ③ gemini 未动

它的流式函数处理 `candidates[].content.parts`，**全文件没有任何
tool_calls / functionCall 处理** —— 连非流式路径也没有。补它不是"对齐"
而是新实现，且 gemini 的 functionCall 形态（`functionCall: {name, args}`，
args 是对象而非 JSON 字符串）与 OpenAI 族不同，需要单独判据。

生产三个源（llmsproxy / visionllm / justworker）全部用 `openai.lua`，
不阻塞。留作独立项。

## 判据

- TestOpenAICompatibleFamilyHandlesStreamToolCalls  5 个 OpenAI 族适配器，
  逐个验证 tool_calls 未丢 + stream_index 正确
- TestAnthropicAdapterEmitsFlatToolCallsWithStreamIndex  用 **Anthropic 协议**
  的 fixture（不用 OpenAI 的，否则会因"不适用该 chunk"跳过 —— 看着绿，
  实则没测）
- TestOllamaAdapterEmitsFlatToolCallsWithStreamIndex  用 Ollama 协议形态
- TestDeepSeekAdapterHandlesStreamToolCalls  单列，因它有源预设指向

★ 三个判据按**协议**分文件而非逐适配器：这几个文件的流式函数逐字相同，
共用一个 fixture 会因协议不适用而静默跳过 —— 那等于没测。

## 体检分类

    修前: ✓ [openai]        ⚠ [kimicode server]  ✗ [anthropic deepseek gemini github groq mistral ollama]
    修后: ✓ [openai deepseek github groq mistral]  ⚠ []  ✗ [gemini]

internal/lua/adapters/kimicode.lua

@@ -95,7 +95,42 @@ function adapter.transform_stream_chunk(raw_chunk)
         unified.reasoning_content = delta.reasoning_content
     end
     if delta.tool_calls then
-        unified.tool_calls = delta.tool_calls
+        local tcs = {}
+        for _, tc in ipairs(delta.tool_calls) do
+            -- OpenAI 流式格式: {function:{name,arguments}, id, type, index}
+            -- homed StreamChunk.ToolCalls 期望扁平格式: {id, type, name, raw_arguments}
+            local fn = tc["function"]
+            local name = (type(fn) == "table" and fn.name) or tc.name or ""
+            local raw_args = ""
+            if type(fn) == "table" and type(fn.arguments) == "string" then
+                raw_args = fn.arguments
+            elseif type(tc.arguments) == "string" then
+                raw_args = tc.arguments
+            end
+            -- 不能按 name 过滤：OpenAI 流式分片中后续块 name 为空但携带 arguments
+            -- accumulateStream 按 index 累积并在 flushToolCall 时校验 name
+            table.insert(tcs, {
+                id = tc.id or "",
+                type = tc.type or "function",
+                name = name,
+                raw_arguments = raw_args,
+                -- ★ 必须透传上游 index（键名是 stream_index，不是 index）。
+                --
+                -- 内核按 stream_index 分桶累积同一轮多个 tool_call 的分片
+                -- （process.go:347 `idx := tc.StreamIndex`）。缺了这一项，
+                -- 所有分片的 StreamIndex 都是缺省 0 ⇒ 全部并进同一个桶 ⇒
+                -- argsRaw 混拼 ⇒ 每个工具都报"参数不是合法 JSON"，
+                -- 而工具一次都没真跑过。
+                --
+                -- 单工具调用时上游 index 恒为 0，缺省也是 0，所以这个问题
+                -- 在生产上长期不显形 —— 直到模型一轮发多个工具才炸。
+                --
+                -- 续传分片（只有 arguments、没有 name）尤其依赖它：
+                -- 那种分片除了 index 没有任何可归位的依据。
+                stream_index = tc.index or 0
+            })
+        end
+        unified.tool_calls = tcs
     end
     return json.encode(unified)
 end