fix: serialize single-text message content as string for OpenAI-compatible APIs

[octo-patch]

Fixes #256

Problem

When using a custom OpenAI-compatible provider (e.g. Groq at https://api.groq.com/openai/v1), the server sends the request body with content as a JSON array even for simple system/user messages that contain a single text part. Many OpenAI-compatible providers are strict about the OpenAI spec and reject this with a 400 error:

'messages.0' → For 'role:system' the following must be satisfied
  [('messages.0.content' → Value must be a string)]

The root cause is that ExtendedChatMessage.Content is typed as []ExtendedChatMessagePart, which always marshals to a JSON array. The ToOpenAI() method already handled this correctly (it returns a plain string when there is exactly one text part), but that path is only used for direct OpenAI API calls. Requests to all other providers go through json.Marshal(extendedReq) which hits the default array serialization.

Solution

Add a MarshalJSON method on ExtendedChatMessage that mirrors the logic in ToOpenAI():

• Single plain-text part, no cache_control, no image_url → emit content as a JSON string (compatible with Groq, Ollama, and the OpenAI spec).
• Multiple parts, or Anthropic cache_control/image_url present → emit content as the existing array (required for Anthropic prompt caching and vision).

This keeps full backward compatibility: Anthropic-style cache-control markers and multimodal content continue to use the array form, while simple text messages use the string form expected by standard OpenAI-compatible APIs.

Testing

• Verified the server builds cleanly (go build ./...).
• The fix mirrors the already-tested ToOpenAI() path; the serialization logic is straightforward and covered by the existing code structure.