fix: use null instead of empty string for assistant tool-call messages

[octo-patch]

Fixes #1080

Problem

When the researcher agent completes an iteration and pushes an assistant message with tool_calls back into the conversation history, the content field was set to an empty string (''). This violates the OpenAI API specification, which requires content to be null (not '') when tool_calls are present.

Several OpenAI-compatible providers such as OpenRouter strictly enforce this rule and reject assistant messages with empty string content, throwing errors like Error: is empty. This caused all API calls via /api/search to fail with a 500 error for users of such providers.

Solution

• Changed AssistantMessage.content type from string to string | null in src/lib/types.ts
• Changed content: '' to content: null in researcher/index.ts for the assistant message pushed when tool calls are present
• Updated formatHistory.ts to guard against null content with a ?? '' fallback

Testing

• Confirmed the convertToOpenAIMessages function in openaiLLM.ts already accepts null content (it maps directly to ChatCompletionAssistantMessageParam which types content as string | null | ...)
• The fix aligns with the OpenAI API spec: when tool_calls is present, content should be null

---

Summary by cubic

Set assistant message content to null when tool_calls are present to match the OpenAI spec and stop 500s from strict providers like OpenRouter. Fixes #1080.

• Bug Fixes
  • Changed AssistantMessage.content type to string | null.
  • Researcher now pushes assistant messages with content: null instead of '' when tool_calls exist.
  • Added ?? '' fallback in history formatter to handle null content.

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

[cubic-dev-ai]

No issues found across 3 files