fix: OpenAI Responses API parallel tool calls losing call_ids

[houssemzaier]

Fixes #8773

When GPT-5 makes parallel tool calls via the Responses API, each function_call has a unique call_id (fc_*). These IDs were being overwritten instead of accumulated, causing:

"No tool call found for function call output with call_id fc_xxx"

Changes

• gui/src/redux/slices/sessionSlice.ts: Accumulate IDs in responsesOutputItemIds[] array during streaming
• core/llm/openaiTypeConverters.ts: Emit function_call for each tool call with positional ID matching
• core/llm/openaiTypeConverters.test.ts: Added comprehensive tests for parallel tool call scenarios

How it works

1. During streaming, when fromResponsesChunk sets message.metadata.responsesOutputItemId, we now accumulate these into an array responsesOutputItemIds[]
2. When converting to Responses API input format, we iterate over all tool calls and match each one with its corresponding fc_ ID by position
3. This ensures each parallel tool call gets its correct call_id when sent back to OpenAI

Test plan

• Unit tests pass (14 new tests covering parallel tool calls, edge cases)
• Manual testing with GPT-5 and GPT-5.1 parallel tool calls

Related: #8935

---

Continue Tasks

Status	Task	Actions
▶️ Queued	Update docs on PR	View

_{Powered by Continue}

---

Summary by cubic

Fixes lost call_id mapping for parallel tool calls in the OpenAI Responses API, preventing “No tool call found for function call output” errors and restoring correct pairing between function_call and tool outputs.

• Bug Fixes
  • Accumulate fc_ IDs during streaming in responsesOutputItemIds[] (keeps the singular field for backward compatibility).
  • Emit a function_call item for each tool call, matching IDs by position; also emit assistant text when present.
  • Add unit tests covering parallel calls, legacy scenarios, and edge cases.

^{Written for commit 4ad4a6e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 3 files